¿Es posible falsificar un certificado CA firmado?

El protocolo de enlace incluye estos pasos (aproximados):

1. El servidor envía su clave pública.
2. El cliente cifra la información de configuración con esa clave pública y la envía al servidor.
3. El servidor descifra el envío del cliente y lo utiliza para derivar un secreto compartido.
4. Los pasos adicionales utilizan ese secreto compartido para configurar el cifrado real que se usará.

Entonces, la respuesta a tu pregunta es que, dado que un impostor no puede realizar el paso 3 (ya que no tiene la clave privada), nunca puede pasar al paso 4. No tiene el secreto compartido, por lo que no puede completar el apretón de manos.

Asudhak, no te sientas mal si esto es un poco confuso. Inventar criptografía asimétrica fue un gran avance en Matemáticas. Parece muy contrario a la intuición, si no abajo, imposible cuando uno lo encuentra por primera vez.

Cuando un cliente (a menudo un navegador web) y un servidor (a menudo un navegador web) desean establecer un canal de comunicaciones seguro, realizan lo que se denomina un "intercambio de claves".

La clave pública que el servidor proporciona al programa cliente no contiene nada secreto. Su única función es cifrar la información.

El cliente genera una contraseña secreta de una sola vez que solo el navegador web conoce. Luego, el cliente utiliza la clave pública del servidor para cifrar que una vez usa una contraseña secreta. La clave pública solo puede cifrar , la clave pública no puede descifrar !

El cliente puede transmitir de forma segura esta contraseña secreta cifrada al servidor. Cualquier persona en el medio que pueda interceptar este intercambio de claves no obtendrá información útil, ya que es casi seguro que no puede descifrar ese secreto de uso único generado por el cliente y cifrado con la clave pública del servidor.

El servidor, y solo el servidor tiene la clave privada correspondiente. La clave privada del servidor solo se puede utilizar para descifrar . ¡La clave privada del servidor nunca se transmite a nadie!

El servidor utiliza la clave privada para descifrar la contraseña secreta de una sola vez que fue generada por el cliente (navegador web).

¡El cliente y el servidor ahora conocen un secreto que nadie más conoce !

Usando este secreto, pueden cifrar sus conversaciones subsiguientes utilizando cualquier algoritmo de cifrado simétrico tradicional con un alto grado de confianza de que el canal es seguro.

Además, el cliente tiene una tienda de ' certificados ' que contiene las claves públicas de las organizaciones en las que confía. Los intercambios de claves TLS reales fallarán si el servidor no presenta un documento digital llamado certificado que contiene un valor de hash cifrado con la clave privada de la organización de confianza. El cliente puede usar este hash y la clave pública de confianza para saber que este servidor se considera confiable.

No podría terminar el TLS handshake cuando el cliente toma el servidor del certificado público y lo utiliza. para cifrar un PreMasterSecret que se utiliza para generar el Secreto Maestro.

  

El cliente responde con un mensaje ClientKeyExchange, que puede contener un PreMasterSecret, una clave pública o nada. (Una vez más, esto depende del cifrado seleccionado). Este PreMasterSecret se cifra mediante la clave pública del certificado del servidor.

     

El cliente y el servidor luego usan los números aleatorios y PreMasterSecret para calcular un secreto común, llamado "secreto maestro". Todos los demás datos clave para esta conexión se derivan de este secreto maestro (y los valores aleatorios generados por el cliente y el servidor), que se pasan a través de una función pseudoaleatoria cuidadosamente diseñada.

Recuerde, en la criptografía asimétrica, la clave pública no es de ninguna manera un secreto y en general (suponiendo que no haya otros defectos) no es de ninguna utilidad para un atacante.

Las respuestas existentes hablan sobre el cifrado con la clave pública del certificado, que no siempre es lo que realmente se usa (en particular con las suites de cifrado DSA o DHE). (Hay una respuesta con más detalles aquí , por ejemplo).

El propósito inmediato del protocolo de enlace SSL / TLS es establecer un secreto de maestro maestro compartido entre el cliente y el servidor. Este secreto pre-maestro luego se deriva en un secreto maestro y luego en claves de cifrado (y MAC). Este procedimiento se conoce más ampliamente como intercambio de claves (consulte RFC 4346 Apéndice F.1.1 ).

Para asegurarse de que se está comunicando con la persona correcta, debe usar un conjunto de cifrado que admita intercambio de claves autenticado . (Las suites de cifrado anónimo están deshabilitadas de forma predeterminada en configuraciones razonables).

Este intercambio de clave autenticado se divide en dos categorías:

• Intercambio de claves RSA (por ejemplo, TLS_RSA_WITH_AES_128_CBC_SHA ): el cliente cifra el secreto maestro previo usando la clave pública del servidor (que se encuentra en el certificado). Solo el servidor legítimo puede descifrar esto con su clave privada.

• Intercambio de claves DHE (por ejemplo, TLS_DHE_RSA_WITH_AES_256_CBC_SHA o conjuntos de cifrado con un certificado DSS): se realiza un intercambio de claves Diffie-Hellman. Generalmente es DH efímero, la variante con parámetros fijos (DH, no DHE) es muy rara. (Tener un certificado basado en RSA no implica un intercambio de claves RSA). El servidor firma sus parámetros DH y el cliente verifica la firma con la clave pública en el certificado del servidor. Dado que solo el servidor legítimo pudo firmar con su clave privada, el intercambio se autentica.

Un método utiliza el cifrado, el otro utiliza la firma digital y ambos utilizan la clave pública en el certificado. Ambos tienen el mismo resultado final: un secreto maestro previo que el cliente puede compartir exclusivamente con el servidor que tiene la clave privada para su certificado.

(Por supuesto, el otro punto es que el cliente debe verificar que confía en que el certificado sea válido y que se emita al servidor con el que desea comunicarse, pero estos son puntos ligeramente separados).

Esto supone que conoce los conceptos básicos de la autenticación de clave pública y cómo un navegador web se comunica con un servidor web a través de un nombre de dominio. La interacción es entre el navegador web del usuario y el servidor web de la empresa.

Claves públicas y claves privadas

El servidor web tiene una clave pública y una clave privada. La clave privada puede descifrar un mensaje cifrado por la clave pública. La clave pública puede descifrar un mensaje cifrado por la clave privada. La autoridad de certificación tiene su propia clave pública y clave privada.

El servidor web envía la información de su empresa, la clave pública y el nombre de dominio (que se asociará con el certificado SSL) a la autoridad de certificación. La autoridad de certificación envía un mensaje de confirmación a la dirección de correo electrónico asociada con el nombre de dominio, a fin de demostrar que esta solicitud fue realizada por el propietario genuino del nombre de dominio. En este punto, la autoridad de certificación esperará hasta que el propietario del nombre de dominio valide la solicitud por correo electrónico.

Firma de certificado

La autoridad de certificación cifra el nombre de dominio del servidor web, la información de la compañía y la clave pública utilizando su propia clave privada. La autoridad de certificación envía el resultado cifrado al servidor web. Este resultado es el certificado SSL, un mensaje de texto que contiene el nombre de dominio, la información de la compañía y la clave pública del servidor web que se ha cifrado con la clave privada de la autoridad de certificación. El servidor web envía este certificado al navegador del usuario.

Autoridades de certificación de confianza

El navegador web viene precargado con una lista de autoridades de certificados de confianza y sus claves públicas. El navegador web descifra el certificado utilizando la clave pública de la autoridad de certificación correspondiente. En este punto, el navegador web sabe que el certificado y su contenido son confiables porque solo un mensaje cifrado con la clave privada de la autoridad certificadora podría haber sido descifrado coherentemente por la clave pública de la autoridad certificadora.

El navegador web ahora conoce la información confiable de la compañía, la clave pública y el nombre de dominio que se supone que están asociados con el servidor web, lo cual aún es sospechoso. El navegador web confirma que el nombre de dominio en el certificado coincide con el nombre de dominio real del servidor web.

En este punto, si los nombres de dominio coinciden, el navegador web determina que el servidor web es lo suficientemente confiable como para enviar datos cifrados. También en este punto, el navegador web determina que puede usar la clave pública confiable del certificado para cifrar sus mensajes porque solo la clave privada del servidor web genuino puede descifrar ese mensaje.

¡Tenga en cuenta que si se usó una clave pública no confiable (sin pasar por la verificación de la autoridad de certificación), el navegador web puede haber cifrado y enviado información confidencial solo para ser descifrada por la clave privada de un servidor malicioso! En otras palabras, es imperativo que se confíe en la clave pública porque cifrar un mensaje con ella es la única línea de defensa contra la información que envía el navegador web.

Continuando, el navegador web cifra su mensaje usando la clave pública de confianza y envía el mensaje cifrado al servidor web. El servidor web descifra el mensaje con la clave privada genuina, si tiene una, luego lee el mensaje descifrado con éxito.

Clave secreta compartida

Cuando el servidor web responde al navegador web, ese mensaje también debe enviarse de forma segura. El navegador web podría copiar lo que el servidor web acaba de hacer (excluyendo el proceso de la autoridad de certificación) al generar una clave pública y una clave privada para luego enviar su clave pública al servidor web. Esto establecería una conexión segura llamada cifrado asimétrico bidireccional. Sin embargo, tal comunicación es gravemente computacional (en términos relativos).

Por lo tanto, el enfoque estándar es usar una clave secreta compartida que pueda cifrar un mensaje y también descifrarlo. El navegador web genera una clave secreta, la cifra mediante la clave pública de confianza y la envía al servidor web. Si el servidor web es original, podrá descifrar la clave secreta con éxito.

En este punto, tanto el navegador web como el servidor web tienen una clave secreta compartida que pueden usar para cifrar y descifrar otras comunicaciones a partir de ahora.

Para leer más:

• Verificación de la integridad del mensaje con funciones hash para detectar alteraciones de mensajes

• Cadena de confianza entre las autoridades de certificación

Que el certificado de CA (clave pública) para los certificados verificados ya está incluido en el navegador y que su escenario generará una advertencia de SSL.

Si está hablando de algo parecido a SSH, todavía deberá aceptar la clave pública. Si no verifica que esa clave sea correcta a través de otro canal seguro, entonces es culpa suya si obtiene MITM'ed.

La respuesta de por qué no puedes simplemente tomar la clave pública firmada y usarla para interceptar el tráfico en un ataque de tipo "hombre en el medio" es que tú (o el atacante) no tendrá la clave privada correspondiente que acompaña a la clave pública.

Por lo tanto, el navegador recibirá los servidores web o las claves públicas firmadas por las CA, y las utilizará para cifrar su propio secreto y enviarlas al servidor web.

El servidor web tiene la clave privada correspondiente necesaria para descifrar los datos enviados por el navegador que estaba cifrado con la clave pública, el atacante no lo hace, por lo que no podrán descifrar el tráfico.

Resulta que hice esta pregunta en 2012, pero ahora, en 2015, hay un ataque que lo hace posible. Dependiendo de la implementación, los clientes pueden ser vulnerables a este ataque, lo que puede permitir que un atacante, un MiTM, pueda falsificar cualquier certificado firmado que desee.

enlace proporciona una explicación detallada de cómo funciona esto debido a la mala implementación de la máquina de estado SSL en el cliente.