Nota: Escribí mi respuesta original muy apresuradamente, pero desde entonces, se ha convertido en una pregunta / respuesta bastante popular, por lo que la he expandido un poco y la he hecho más precisa.
Capacidades TLS
"SSL" es el nombre que se usa con mayor frecuencia para referirse a este protocolo, pero SSL se refiere específicamente al protocolo patentado diseñado por Netscape a mediados de los 90. "TLS" es un estándar IETF que se basa en SSL, por lo que utilizaré TLS en mi respuesta. En estos días, lo más probable es que casi todas sus conexiones seguras en la web realmente estén usando TLS, no SSL.
TLS tiene varias capacidades:
- Cifre los datos de la capa de su aplicación. (En su caso, el protocolo de la capa de aplicación es HTTP).
- Autentique el servidor al cliente.
- Autenticar el cliente al servidor.
# 1 y # 2 son muy comunes. # 3 es menos común. Parece que te estás enfocando en el n. ° 2, así que explicaré esa parte.
Autenticación
Un servidor se autentica ante un cliente utilizando un certificado. Un certificado es un conjunto de datos [1] que contiene información sobre un sitio web:
- Nombre de dominio
- Llave pública
- La empresa propietaria
- Cuando fue emitido
- Cuando expira
- Quien lo emitió
- Etc.
Puede lograr la confidencialidad (# 1 arriba) mediante el uso de la clave pública incluida en el certificado para cifrar mensajes que solo pueden ser descifrados por la clave privada correspondiente, que debe almacenarse de forma segura en ese servidor. [2] Llamemos a este par de claves KP1, para que no nos confundamos más adelante. También puede verificar que el nombre de dominio en el certificado coincida con el sitio que está visitando (# 2 arriba).
Pero, ¿qué sucede si un adversario puede modificar los paquetes enviados hacia y desde el servidor, y qué sucede si ese adversario modificó el certificado que se le presentó e insertó su propia clave pública o cambió cualquier otro detalle importante? Si eso sucediera, el adversario podría interceptar y modificar cualquier mensaje que creía que estaba cifrado de forma segura.
Para evitar este mismo ataque, el certificado está firmado criptográficamente por la clave privada de otra persona de tal manera que cualquier persona que tenga la clave pública correspondiente puede verificar la firma. Llamemos a este par de claves KP2, para dejar en claro que estas no son las mismas claves que está utilizando el servidor.
Autoridades de certificación
Entonces, ¿quién creó KP2? ¿Quién firmó el certificado?
Simplificando un poco, una autoridad de certificación crea KP2 y venden el servicio de usar su clave privada para firmar certificados para otras organizaciones. Por ejemplo, creo un certificado y le pago a una empresa como Verisign para que lo firme con su clave privada. [3] Como nadie más que Verisign tiene acceso a esta clave privada, ninguno de nosotros puede falsificar esta firma.
¿Y cómo conseguiría personalmente la clave pública en KP2 para verificar esa firma?
Bueno, ya hemos visto que un certificado puede contener una clave pública, y los informáticos adoran la recursividad, entonces, ¿por qué no poner la clave pública KP2 en un certificado y distribuirla de esa manera? Esto suena un poco loco al principio, pero de hecho así es exactamente como funciona. Continuando con el ejemplo de Verisign, Verisign produce un certificado que incluye información sobre quiénes son, qué tipos de cosas se les permite firmar (otros certificados) y su clave pública.
Ahora, si tengo una copia de ese certificado de Verisign, puedo usarla para validar la firma en el certificado del servidor para el sitio web que deseo visitar. Fácil, ¿verdad?
Bueno, no tan rápido. Tenía que obtener el certificado de Verisign de alguna parte . ¿Qué pasa si alguien falsifica el certificado Verisign y pone su propia clave pública allí? Luego pueden falsificar la firma en el certificado del servidor, y estamos de vuelta donde comenzamos: un ataque de hombre en el medio.
Cadenas de certificados
Continuando con la reflexión recursiva, podríamos, por supuesto, introducir un tercer certificado y un tercer par de claves (KP3) y usarlo para firmar el certificado Verisign. Llamamos a esto una cadena de certificados: cada certificado de la cadena se utiliza para verificar el siguiente certificado. Con suerte, ya puede ver que este enfoque recursivo es solo tortugas / certificados hasta el final. ¿Dónde se detiene?
Puesto que no podemos crear un número infinito de certificados, la cadena de certificados, obviamente, tiene que parar en alguna parte , y que ha hecho mediante la inclusión de un certificado de la cadena que es auto-firmado .
Me detendré por un momento mientras recoges los pedazos de materia cerebral de tu cabeza explotando. ¿Autofirmado?
Sí, al final de la cadena de certificados (también conocida como "raíz"), habrá un certificado que usa su propio par de claves para firmarse. Esto elimina el problema de recursión infinita, pero no soluciona el problema de autenticación. Cualquiera puede crear un certificado autofirmado que diga cualquier cosa, al igual que yo puedo crear un falso diploma de Princeton que diga que me especialicé en política, física teórica y aplicando patadas en el trasero y luego firmo mi propio nombre en la parte inferior.
La solución [algo poco emocionante] a este problema es elegir un conjunto de certificados autofirmados en los que confía explícitamente. Por ejemplo, podría decir: " Confío en este certificado autofirmado de Verisign".
Con esa confianza explícita en su lugar, ahora puedo validar toda la cadena de certificados. No importa cuántos certificados haya en la cadena, puedo validar cada firma hasta la raíz. Cuando llego a la raíz, puedo verificar si ese certificado raíz es uno en el que confío explícitamente. Si es así, entonces puedo confiar en toda la cadena.
Fideicomiso Conferido
La autenticación en TLS utiliza un sistema de confianza conferida . Si quiero contratar a un mecánico de automóviles, es posible que no confíe en ningún mecánico aleatorio que encuentre. Pero tal vez mi amigo responde por un mecánico en particular. Como confío en mi amigo, puedo confiar en ese mecánico.
Cuando compra una computadora o descarga un navegador, viene con unos cientos de certificados raíz en los que confía explícitamente. [4] Las compañías que poseen y operan esos certificados pueden conferir esa confianza a otras organizaciones firmando sus certificados.
Esto está lejos de ser un sistema perfecto. Algunas veces una CA puede emitir un certificado por error. En esos casos, es posible que sea necesario revocar el certificado. La revocación es complicada ya que el certificado emitido siempre será criptográficamente correcto; Es necesario un protocolo fuera de banda para averiguar qué certificados previamente válidos han sido revocados. En la práctica, algunos de estos protocolos no son muy seguros, y muchos navegadores no los verifican de todos modos.
A veces, toda una CA está comprometida. Por ejemplo, si entrara a Verisign y robara su clave de firma raíz, podría falsificar cualquier certificado del mundo. Tenga en cuenta que esto no solo afecta a los clientes de Verisign: incluso si mi certificado está firmado por Thawte (un competidor de Verisign), eso no importa. Mi certificado aún se puede falsificar utilizando la clave de firma comprometida de Verisign.
Esto no es solo teórico. Ha sucedido en la naturaleza. DigiNotar fue famoso hackeado y posteriormente se declaró en quiebra. Comodo también fue pirateado , pero inexplicablemente siguen en el negocio hasta el día de hoy.
Incluso cuando las CA no están directamente comprometidas, existen otras amenazas en este sistema. Por ejemplo, un gobierno usa la coerción legal para obligar a una AC a firmar un certificado falsificado. Su empleador puede instalar su propio certificado de CA en la computadora de su empleado. En estos diversos casos, el tráfico que espera que sea "seguro" es en realidad completamente visible / modificable para la organización que controla ese certificado.
Se han sugerido algunos reemplazos, incluidos Convergence , TACK y DANE .
Notas finales
[1] Los datos del certificado TLS están formateados de acuerdo con el estándar X.509 . X.509 se basa en ASN.1 ( "notación de sintaxis abstracta # 1"), lo que significa que es no un formato de datos binarios. Por lo tanto, X.509 debe estar codificado en un formato binario. DER y PEM son las dos codificaciones más comunes que conozco.
[2] En la práctica, el protocolo en realidad cambia a un cifrado simétrico, pero ese es un detalle que no es relevante para su pregunta.
[3] Presumiblemente, la CA realmente valida quién eres antes de firmar tu certificado. Si no lo hicieron, podría crear un certificado para google.com y pedirle a una CA que lo firme. Con ese certificado, podría establecer una conexión "segura" con google.com. Por lo tanto, el paso de validación es un factor muy importante en el funcionamiento de una CA. Desafortunadamente, no está muy claro cuán riguroso es este proceso de validación en los cientos de AC de todo el mundo.
[4] Ver la lista de Mozilla de CA confiables .
