¿Cómo se verifican los certificados SSL?
¿Cuál es la serie de pasos necesarios para verificar de forma segura un certificado SSL? Mi entendimiento (muy limitado) es que cuando visita un sitio https, el servidor envía un certificado al cliente (el navegador) y el navegador obtiene la información del emisor del certificado de ese certificado, luego la usa para contactar al emisor y de alguna manera compara certificados de validez.
- ¿Cómo se hace esto exactamente?
- ¿Qué pasa con el proceso que lo hace inmune a los ataques del intermediario?
- ¿Qué impide que una persona cualquiera configure su propio servicio de verificación para utilizarlo en ataques de intermediario, de modo que todo "parezca" seguro?
Aquí tienes una explicación muy simplificada:
Su navegador web descarga el certificado del servidor web, que contiene la clave pública del servidor web. Este certificado está firmado con la clave privada de una autoridad certificadora confiable.
Su navegador web viene instalado con las claves públicas de todas las principales autoridades certificadoras. Utiliza esta clave pública para verificar que el certificado del servidor web haya sido efectivamente firmado por la autoridad certificadora confiable.
El certificado contiene el nombre de dominio y/o la dirección IP del servidor web. Su navegador web confirma con la autoridad certificadora que la dirección que figura en el certificado es aquella con la que tiene una conexión abierta.
El navegador y el servidor calculan una clave simétrica compartida que se utiliza para el cifrado de datos real. Dado que se verifica la identidad del servidor, el cliente puede estar seguro de que este "intercambio de claves" se realiza con el servidor correcto y no con un atacante intermedio.
Tenga en cuenta que la autoridad de certificación (CA) es esencial para prevenir ataques de intermediario. Sin embargo, incluso un certificado sin firmar evitará que alguien escuche pasivamente su tráfico cifrado, ya que no tiene forma de obtener acceso a su clave simétrica compartida.
dijiste eso
el navegador obtiene la información del emisor del certificado de ese certificado, luego la usa para contactar al emisor y de alguna manera compara la validez de los certificados.
El cliente no tiene que consultar con el emisor por dos cosas:
- Todos los navegadores tienen una lista preinstalada de todas las claves públicas de las principales CA.
- el certificado está firmado, y esa firma en sí es prueba suficiente de que el certificado es válido porque el cliente puede asegurarse, por sí solo, y sin contactar con el servidor del emisor, de que ese certificado es auténtico. Ésa es la belleza del cifrado asimétrico.
Observe que 2. no se puede hacer sin 1.
Esto se explica mejor en este gran diagrama que hice hace algún tiempo.
(salte a "¿qué es una firma?" en la parte inferior)
Vale la pena señalar que además de comprar un certificado (como se mencionó anteriormente), también puedes crear el tuyo propio de forma gratuita; esto se conoce como "certificado autofirmado". La diferencia entre un certificado autofirmado y uno comprado es simple: el comprado ha sido firmado por una Autoridad de Certificación que su navegador ya conoce. En otras palabras, su navegador puede validar fácilmente la autenticidad de un certificado adquirido.
Desafortunadamente, esto ha llevado a una idea errónea de que los certificados autofirmados son inherentemente menos seguros que los vendidos por CA comerciales como GoDaddy y Verisign, y que hay que vivir con advertencias/excepciones del navegador si los usa; Esto es incorrecto .
Si distribuye de forma segura un certificado autofirmado (o certificado CA, como sugirió Bobince) y lo instala en los navegadores que utilizarán su sitio , es tan seguro como uno comprado y no es vulnerable al intermediario. ataques y falsificación de certificados. Obviamente, esto significa que sólo es factible si sólo unas pocas personas necesitan acceso seguro a su sitio (por ejemplo, aplicaciones internas, blogs personales, etc.).
SÉ QUE LO SIGUIENTE ES LARGO, PERO ES DETALLADO, PERO SUFICIENTEMENTE SIMPLIFICADO. LEA DETENIDAMENTE Y LE GARANTIZO QUE COMENZARÁ A ENCONTRAR QUE ESTE TEMA NO ES TAN COMPLICADO.
En primer lugar, cualquiera puede crear 2 claves. Uno para cifrar datos y otro para descifrar datos. La primera puede ser clave privada, y la segunda pública, Y VICERZA.
En segundo lugar, en términos más simples, una Autoridad de Certificación (CA) ofrece el servicio de crear un certificado para usted. ¿Cómo? Utilizan ciertos valores (el nombre del emisor de la CA, la clave pública de su servidor, el nombre de la empresa, el dominio, etc.) y utilizan su clave privada SUPER DUPER ULTRA SECURE SECRET y cifran estos datos. El resultado de estos datos cifrados es una FIRMA.
Ahora la CA le devuelve un certificado. El certificado es básicamente un archivo que contiene los valores mencionados anteriormente (nombre del emisor de la CA, nombre de la empresa, dominio, clave pública de su servidor, etc.), INCLUYENDO la firma (es decir, una versión cifrada de estos últimos valores).
Ahora, habiendo dicho todo esto, aquí hay una parte REALMENTE IMPORTANTE para recordar: su dispositivo/SO (Windows, Android, etc.) prácticamente mantiene una lista de todas las CA principales/confiables y sus CLAVES PÚBLICAS (si está pensando que estas claves públicas se utilizan para descifrar las firmas dentro de los certificados, ¡ ESTÁS EN CORRECTO! ).
Ok, si lees lo anterior, este ejemplo secuencial será muy sencillo ahora:
- Ejemplo-Compañía le pide a Ejemplo-CA que les cree un certificado.
- Ejemplo-CA utiliza su clave súper privada para firmar este certificado y le entrega el certificado a Ejemplo-Compañía.
- Mañana, el usuario de Internet Bob usa Chrome/Firefox/etc. para navegar a https://example-company.com . La mayoría de los navegadores actuales, si no todos, esperarán un certificado del servidor.
- El navegador obtiene el certificado de example-company.com. El certificado dice que ha sido emitido por Ejemplo-CA. Da la casualidad de que el sistema operativo de Bob ya tiene Ejemplo-CA en su lista de CA confiables, por lo que el navegador obtiene la clave pública de Ejemplo-CA. Recuerde: todo esto sucede en la computadora/móvil/etc. de Bob, no a través del cable.
- Ahora el navegador descifra la firma en el certificado. FINALMENTE, el navegador compara los valores descifrados con el contenido del propio certificado. SI EL CONTENIDO COINCIDE, ¡ESO SIGNIFICA QUE LA FIRMA ES VÁLIDA!
¿Por qué? Piénselo, solo esta clave pública puede descifrar la firma de tal manera que el contenido tenga el mismo aspecto que tenía antes de que la clave privada lo cifrara.
¿Qué tal los ataques del hombre en el medio?
Esta es una de las razones principales (si no la razón principal) por la que se creó el estándar anterior.
Digamos que la hacker Jane intercepta la solicitud del usuario de Internet Bob y responde con su propio certificado. Sin embargo, la hacker Jane sigue siendo lo suficientemente cuidadosa como para indicar en el certificado que el emisor era Ejemplo-CA. Por último, Jane-hacker recuerda que debe incluir una firma en el certificado. Pero, ¿qué clave usa Jane para firmar (es decir, crear un valor cifrado del contenido principal del certificado) el certificado?????
Entonces, incluso si la hacker Jane firmó el certificado con su propia clave, ya verás lo que sucederá a continuación. El navegador dirá: "ok, este certificado lo emite Ejemplo-CA, desciframos la firma con la clave pública de Ejemplo-CA". Después del descifrado, el navegador nota que el contenido del certificado no coincide en absoluto. Por lo tanto, el navegador da una advertencia muy clara al usuario y dice que no confía en la conexión.
