google - ¿Cómo funciona realmente SSL?

ssl certificate price

Question

¿Cómo funciona SSL?

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

¿Cómo comienza el proceso de confianza / encriptación / 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é no puede HTTP trabajar con certificados cuando son los certificados los que hacen todo el trabajo de confianza / encriptación / autenticación?

Answer 1

Nota: Escribí mi respuesta original muy apresuradamente, pero desde entonces, esto 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 de TLS

"SSL" es el nombre que se usa con más 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 usaré TLS en mi respuesta. Estos días, las probabilidades son que casi todas sus conexiones seguras en la web realmente usan TLS, no SSL.

TLS tiene varias capacidades:

1. Encripta los datos de tu capa de aplicación. (En su caso, el protocolo de capa de aplicación es HTTP).
2. Autentica el servidor al cliente.
3. Autentica el cliente al servidor.

# 1 y # 2 son muy comunes. # 3 es menos común. Pareces centrarte en el n. ° 2, así que te explicaré esa parte.

Autenticación

Un servidor se autentica a un cliente que usa 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 compañía que lo posee
• Cuando fue emitido
• Cuando expira
• Quién lo emitió
• Etc.

Puede lograr la confidencialidad (n. ° 1 anterior) mediante el uso de la clave pública incluida en el certificado para cifrar mensajes que solo pueden descifrarse mediante la clave privada correspondiente, que debe almacenarse de forma segura en ese servidor. [2] Vamos a llamar 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 (n. ° 2 arriba).

Pero, ¿qué pasaría si un adversario pudiese modificar los paquetes enviados al servidor y desde él, y qué pasaría si ese adversario modificara el certificado que le presentaron e insertara su propia clave pública o cambiara cualquier otro detalle importante? Si eso sucediera, el adversario podría interceptar y modificar cualquier mensaje que creyera que estaba encriptado de manera segura.

Para evitar este ataque, el certificado está firmado criptográficamente por la clave privada de otra persona de forma tal que cualquier persona que tenga la clave pública correspondiente pueda verificar la firma. Llamemos a este par de claves KP2, para dejar en claro que estas no son las mismas claves que el servidor está utilizando.

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 pago a una empresa como Verisign para que 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 podría obtener 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 científicos informáticos adoran la recursión, ¿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 como funciona. Siguiendo con el ejemplo de Verisign, Verisign produce un certificado que incluye información sobre quiénes son, qué tipos de cosas pueden firmar (otros certificados) y su clave pública.

Ahora, si tengo una copia de ese certificado de Verisign, puedo usarlo 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 algún lado . ¿Qué pasa si alguien burla el certificado de 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 certificado

Continuando pensando de forma recursiva, podríamos, por supuesto, presentar un tercer certificado y un tercer par de claves (KP3) y usarlo para firmar el certificado de Verisign. Llamamos a esto una cadena de certificados: cada certificado de la cadena se utiliza para verificar el próximo certificado. Con suerte, ya se puede ver que este enfoque recursivo es solo tortugas / certificados hasta el final. ¿Dónde se detiene?

Como no podemos crear un número infinito de certificados, la cadena de certificados obviamente tiene que detenerse en alguna parte , y eso se hace incluyendo un certificado en la cadena que está autofirmado.

Me detendré por un momento mientras recoges los pedazos de materia cerebral de tu cabeza explotando. ¡¿Firmado por sí mismo ?!

Sí, al final de la cadena de certificados (también conocido como "raíz"), habrá un certificado que usa su propio par de llaves para firmar. Esto elimina el problema de recursión infinita, pero no soluciona el problema de autenticación. Cualquiera puede crear un certificado autofirmado que diga algo al respecto, del mismo modo que puedo crear un falso diploma de Princeton que dice que triplemente me especialicé en política, física teórica y aplicación de puntapiés y luego firmo mi propio nombre en la parte inferior.

La solución [un tanto aburrida] a este problema es simplemente elegir un conjunto de certificados autofirmados en los que confíe 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 llegue 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.

Confianza Confiere

La autenticación en TLS usa un sistema de confianza conferida . Si quiero contratar un mecánico automotriz, no puedo confiar en ningún mecánico al azar que encuentre. Pero tal vez mi amigo responde por un mecánico en particular. Como confío en mi amigo, entonces puedo confiar en ese mecánico.

Cuando compras una computadora o descargas un navegador, viene con unos cientos de certificados raíz en los que confía explícitamente. [4] Las empresas que poseen y operan esos certificados pueden conferir esa confianza a otras organizaciones mediante la firma de sus certificados.

Esto está lejos de ser un sistema perfecto. Algunas veces una CA puede emitir un certificado erróneamente. En esos casos, el certificado puede necesitar ser revocado. La revocación es engañosa 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 controlan de todos modos.

A veces, una CA completa se ve comprometida. Por ejemplo, si ingresas a Verisign y robas su clave de firma raíz, puedes falsificar cualquier certificado en el 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 tiene importancia. Mi certificado todavía puede falsificarse utilizando la clave de firma comprometida de Verisign.

Esto no es solo teórico. Ha sucedido en la naturaleza. DigiNotar fue famoso pirateado y posteriormente se declaró en quiebra. Comodo también fue hackeado , pero inexplicablemente permanecen 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 utiliza la coacción legal para obligar a un CA a firmar un certificado falsificado. Su empleador puede instalar su propio certificado de CA en su computadora de empleado. En estos varios casos, el tráfico que espera que sea "seguro" es realmente completamente visible / modificable para la organización que controla ese certificado.

Se han sugerido algunos reemplazos, incluidos Convergence , TACK y DANE .

Notas al final

[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 n.º 1"), lo que significa que no es 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 realmente cambia a un cifrado simétrico, pero ese es un detalle que no es relevante para tu pregunta.

[3] Presumiblemente, la CA realmente valida quién es usted antes de firmar su certificado. Si no hicieran eso, entonces podría crear un certificado para google.com y pedirle a un CA que lo firme. Con ese certificado, podría man-en-el-medio cualquier 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 CA de todo el mundo.

[4] Consulte la lista de CA de confianza de Mozilla.

Answer 2

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

SSL Handshake

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 CA de confianza local, el cliente genera una clave de sesión secreta, la encripta usando el servidor público clave y lo envía. El servidor descifra la clave de la sesión secreta con su clave privada y envía un acuse de recibo al cliente. Se estableció un canal seguro.

Answer 3

Mehaase ya lo explicó en detalle. Agregaré mis 2 centavos a esta serie. Tengo muchas publicaciones de blog relacionadas con el protocolo de enlace SSL y los certificados. 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:

• SSL Handshake e IIS
• Certificado de cliente Autenticación en SSL Handshake

No trate CERTIFICADOS y SSL como un tema. Trátelos como 2 temas diferentes y luego intente 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 la Tienda de certificados

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 intermedias 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á determinar 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 busca AIA para esto). El cliente también realiza una verificación similar para el certificado del servidor que recibe en el Servidor Hola. En Windows, puede ver las tiendas de certificados para el cliente y el servidor a través de PowerShell. Ejecute lo siguiente desde una consola de 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 por separado.

El protocolo de enlace SSL utiliza criptografía simétrica y de clave pública. La autenticación del servidor ocurre de forma 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. Consulte la publicación de mi blog como lo he explicado en detalle.

Finalmente para esta pregunta

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

Certificados es simplemente un archivo cuyo formato está definido por el estándar X.509 . Es un documento electrónico que demuestra la identidad de una parte que se comunica. HTTPS = HTTP + SSL es un protocolo que define las pautas sobre cómo las 2 partes deben comunicarse 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 entendido esto, proceda con el protocolo de enlace TLS / SSL. Puede referir el RFC para esto. Pero son el esqueleto que define las pautas. Hay varias publicaciones de blog, incluida la mía, que explican esto en detalle.

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

Answer 4

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 se aloja aquí).

¿Por qué es necesario?

HTTPS cifra los datos que se transmiten de un navegador a otro a través de la red. Entonces, 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 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 con el servidor de payment.com. Encripta K bajo la clave pública de payment.com.
5. payment.com descifra K utilizando su clave privada. Ahora, tanto el navegador como el servidor de pagos conocen K, pero nadie más lo hace.
6. Cada vez que el navegador quiera enviar algo a payment.com, lo cifra en K; el servidor de payment.com lo descifra al recibirlo. Cada vez que el servidor de payment.com desee enviar algo a su navegador, lo cifra en virtud de K.

Este flujo se puede representar mediante el siguiente diagrama: