¿Cómo funciona SSL?

¿Dónde está instalado el certificado en el cliente (o navegador) y el servidor (o servidor web?)?

¿Cómo comienza el proceso de confianza / cifrado / autenticación cuando ingresas la URL en el navegador y obtienes la página del servidor?

¿Cómo reconoce el protocolo HTTPS el certificado? ¿Por qué HTTP no puede trabajar con certificados cuando son los certificados los que hacen todo el trabajo de confianza / cifrado / autenticación?

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:

1. Cifre los datos de la capa de su aplicación. (En su caso, el protocolo de la capa de aplicación es HTTP).
2. Autentique el servidor al cliente.
3. 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 .

HTTPS es una combinación de HTTP y SSL (Secure Socket Layer) para proporcionar comunicación encriptada entre el cliente (navegador) y el servidor web (la aplicación está alojada aquí).

¿Por qué es necesario?

HTTPS cifra los datos que se transmiten del navegador al servidor a través de la red. Por lo tanto, nadie puede oler los datos durante la transmisión.

¿Cómo se establece la conexión HTTPS entre el navegador y el servidor web?

1. El navegador intenta conectarse a https://payment.com .
2. El servidor de payment.com envía un certificado al navegador. Este certificado incluye la clave pública del servidor de payment.com y alguna evidencia de que esta clave pública realmente pertenece a payment.com.
3. El navegador verifica el certificado para confirmar que tiene la clave pública adecuada para payment.com.
4. El navegador elige una nueva clave simétrica aleatoria K para usar para su conexión al servidor de payment.com. Cifra K bajo la clave pública de payment.com.
5. payment.com descifra K usando su clave privada. Ahora, tanto el navegador como el servidor de pago conocen K, pero nadie más lo sabe.
6. Cada vez que el navegador desea enviar algo a payment.com, lo cifra bajo K; el servidor de payment.com lo descifra al recibirlo. Cada vez que el servidor de payment.com quiere enviar algo a su navegador, lo cifra bajo K.

Este flujo puede representarse mediante el siguiente diagrama:

He escrito una pequeña publicación en el blog que analiza brevemente el proceso. Por favor, siéntase libre de echar un vistazo.

Apretón de manos SSL

Un pequeño fragmento del mismo es el siguiente:

"El cliente realiza una solicitud al servidor a través de HTTPS. El servidor envía una copia de su certificado SSL + clave pública. Después de verificar la identidad del servidor con su almacén de CA de confianza local, el cliente genera una clave de sesión secreta, la cifra utilizando el servidor público clave y la envía. El servidor descifra la clave de sesión secreta utilizando su clave privada y envía un acuse de recibo al cliente. Se estableció un canal seguro ".

Mehaase ya lo ha explicado en detalle. Agregaré mis 2 centavos a esta serie. Tengo muchas publicaciones de blog que giran en torno al protocolo de enlace y certificados SSL. Si bien la mayor parte de esto gira en torno al servidor web IIS, la publicación sigue siendo relevante para el protocolo de enlace SSL / TLS en general. Aquí hay algunos para su referencia:

• Apretón de manos SSL e IIS
• Autenticación de certificado de cliente en SSL Handshake

No trate los CERTIFICADOS Y SSL como un tema. Trátelos como 2 temas diferentes y luego trate de ver con quién trabajan en conjunto. Esto te ayudará a responder la pregunta.

Establecer confianza entre las partes que se comunican a través de Certificate Store

La comunicación SSL / TLS funciona únicamente sobre la base de la confianza. Cada computadora (cliente / servidor) en Internet tiene una lista de CA raíz y CA intermedia que mantiene. Estos se actualizan periódicamente. Durante el protocolo de enlace SSL, esto se utiliza como referencia para establecer la confianza. Por ejemplo, durante el protocolo de enlace SSL, cuando el cliente proporciona un certificado al servidor. El servidor intentará verificar si la CA que emitió el certificado está presente en su lista de CA. Cuando no puede hacer esto, declara que no pudo hacer la verificación de la cadena de certificados. (Esta es una parte de la respuesta. También analiza AIApara esto.) El cliente también realiza una verificación similar para el certificado del servidor que recibe en Server Hello. En Windows, puede ver los almacenes de certificados para cliente y servidor a través de PowerShell. Ejecute lo siguiente desde una consola PowerShell.

PS Cert:> ls Ubicación: CurrentUser StoreNames: {TrustedPublisher, ClientAuthIssuer, Root, UserDS ...}

Ubicación: LocalMachine StoreNames: {TrustedPublisher, ClientAuthIssuer, Escritorio remoto, Root ...}

Los navegadores como Firefox y Opera no dependen del sistema operativo subyacente para la gestión de certificados. Mantienen sus propias tiendas de certificados separadas.

El protocolo de enlace SSL utiliza criptografía de clave pública y simétrica. La autenticación del servidor ocurre de manera predeterminada. La autenticación del cliente es opcional y depende de si el punto final del servidor está configurado para autenticar al cliente o no. Refiera mi publicación de blog ya que lo he explicado en detalle.

Finalmente para esta pregunta

¿Cómo reconoce el protocolo HTTPS el certificado? ¿Por qué HTTP no puede trabajar con certificados cuando son los certificados los que hacen todo el trabajo de confianza / cifrado / autenticación?

Los certificados son simplemente un archivo cuyo formato está definido por el estándar X.509 . Es un documento electrónico que prueba la identidad de una parte comunicante. HTTPS = HTTP + SSL es un protocolo que define las pautas sobre cómo deben comunicarse 2 partes entre sí.

MÁS INFORMACIÓN

• Para comprender los certificados, deberá comprender qué son los certificados y también leer sobre la Gestión de certificados. Esto es importante
• Una vez que se entiende esto, continúe con el protocolo de enlace TLS / SSL. Puede consultar los RFC para esto. Pero son esqueletos que definen las pautas. Hay varias publicaciones de blog, incluida la mía, que explican esto en detalle.

Si se realiza la actividad anterior, tendrá una comprensión justa de los certificados y SSL.