Re: [GALPon] certificacion de clave publica

On Sun, 2013-02-17 at 13:47 +0100, Odo wrote: A ver, está difícil, a ver, cómo lo ponemos fácil. No sé si puedo explicarte lo que necesitas (cuando compras un certificado, es mejor seguir los pasos que el proveedor te sugiere, desde cómo generar tus llaves hasta cómo instalarlas). Pero te puedo explicar las bases del sistema, como un cuentito. Probablemente me corrijan, escribí sobre esto hace mucho, así que necesito refrescar la memoria. D emis notas: Bender: Hey, brobot, what's your serial number? Flexo: 3370318 Bender: No way! Mine's 2716057! (Everyone laughs) Fry: I don't get it. Bender and Flexo: We're both expressible as the sum of two cubes! Wahoo! -- Futurama episode 1ACV06 (The Lesser of Two Evils) http://www.wired.com/entertainment/hollywood/magazine/15-12/ff_futurama_gee… Para ponertelo fácil: Bender y Flexo tienen números seriales que resultan de la suma de dos cubos. Es fácil calcular la suma si tienes los cubos, pero difícil de calcular las raíces si sólo tienes la suma. Ej: 1729 = 1³ + 12³ = 9³ + 10³ C=A³+B³ Por tanto, si tienes A y B es fácil calcular C, pero si tienes C es difícil calcular A y B. Bender y Flexo deben tener procesadores poderosos para calcular eso en un segundo. Por otra parte, la encriptación asimétrica usa una llave para encriptar y otra diferente para desencriptar. Junta esos dos conceptos y ya tienes la base de la PKI (public key infrastructure). C es la llave pública (todos la pueden conocer, sirve sólo para encriptar) y A y B son la llave privada (sólo la conoce el servidor, sirve para desencriptar). Ahora, cómo comunicarte con seguridad con un servidor? cuando tu navegador abre https://www.gmail.com (ojo con el httpS), recibe una llave pública C, de google. Cómo se asegura de que esa llave es efectivamente de gmail? Consulta la CA (certificate authority), una base de claves autorizadas. Si está, tu navegador está seguro de que está comunicándose con google. Entonces continúa. Si no, te abre la ventanita diciendo "esa llave no es válida". Luego, tu navegador crea una llave simétrica S y encripta el mensaje con C. El servidor obtiene la llave S desencriptando el mensaje con A y B. Todo mensaje que te envíe se encripta con S. Todo mensaje que tú envíes se encripta con C. Listo, mensajes asegurados. Ojo, que el servidor te envía los mensajes encriptados con la llave que tú le diste, S. Él envía mensajes encriptados, tú también. Este proceso se llama SSH handshake. Así funciona el sistema (leí que chrome tiene sus propias llaves privadas, pero no lo sé, la verdad no lo creo, pues no tiene mucho sentido). El gobierno te da una llave, esa sí que es del cliente. El problema tuyo es obtener la confianza de un navegador (o cualquier otro tipo de cliente, correo, ssh, etc.). Hasta donde entiendo, las llaves se firman (firma digital) mediante un algoritmo similar. La cuestión es que hay varios formatos de certificados y de firmas. Aquí es donde te digp que es mejor escuchar las sugerencias del proveedor. Básicamente tú no puedes crear una CA (bueno, puedes, pero ningun navegador la acepta POR DEFECTO). Pero sí creas las llaves de tu servidor (.KEY). Luego solicitas la firma de esa llave (.CSR, certificate signing request). Entregas esas al proveedor, el proveedor firma y te devuelve el certificado firmado. Ese es el que instalas en tu server. Luego los navegadores ya no muestran mensajes de error cuando pasas páginas por https. Si quieres ver formatos (normalmente todas las llaves openssl son legibles), crea un self-signed certificate. Ahí verás todos los certificados, desde el CA hasta el PKCS12 o esas curiosas llaves que se instalan en outlook. Google is your friend. Verás que hay MUCHAS opciones para solicitudes de firma, CAs, llaves, etcs. O también puedes curiosear el directorio /etc/pki, los Makefile, el ejecutable CA, etc. Es lo poco que recuerdo. Saludos.