¿Cómo se compromete el intercambio de claves no efímero Diffie-Hellman en SSL cuando se filtra la clave privada RSA?

Primero, asegurémonos de que hablamos de lo mismo. En SSL , hay "suites de cifrado DH efímeras" (DHE) y "conjuntos de cifrado DH no efímeros" (DH) .

Con DHE, la clave privada del servidor (la permanente, la que está almacenada en un archivo y cuya clave pública está en el certificado del servidor) es de tipo RSA (conjuntos de cifrado DHE_RSA) o DSS (conjuntos de cifrado DHE_DSS) , y se usa solo para firmas . El servidor genera un nuevo par de claves DH aleatorias (la clave privada no se almacenará, que es cómo avance perfecto se logra el secreto : una clave privada no puede ser robada después si nunca ha sido almacenada), y envía la clave pública al cliente, en un mensaje que el servidor firma con su clave privada RSA o DSS.

Con las suites de cifrado DH, la clave privada permanente del servidor es una clave privada DH. El certificado del servidor contiene la clave pública DH. El servidor no puede ver que su clave RSA sea robada porque el servidor no tiene una clave RSA. El servidor solo tiene una clave DH Cuando una suite de cifrado se llama "DH_RSA", significa "la clave del servidor es una clave DH y el certificado del servidor fue emitido (es decir, firmado) por una Autoridad de Certificación que usa una clave RSA ".

El robo de la clave privada DH de una de las partes involucradas en un intercambio de claves DH permite una ulterior reconstrucción del secreto compartido, al igual que RSA. En "DH efímero", el PFS se obtiene a través de "efímero", no a través de "DH". Técnicamente, sería posible tener "RSA efímero" pero no se hace en la práctica (*) porque generar un nuevo par de claves RSA es un poco caro, mientras que producir un nuevo par de claves DH es barato.

^{(*) Las claves RSA efímeras eran posibles con versiones antiguas de SSL como parte de las suites de cifrado de "exportación", destinadas a cumplir con las regulaciones de exportación de EE. UU. anteriores a 2000: el servidor podría tener un valor de 1024 bits < em> firma clave RSA y genere un par de claves RSA de 512 bits efímero para el intercambio de claves, que se utiliza en el modo de cifrado. Sin embargo, no recuerdo haber visto eso en la naturaleza, y es un punto discutible desde que se levantaron las regulaciones de exportación de EE. UU. Sobre tamaños de clave.}

Existen conjuntos de cifrado DH no efímeros para permitir que los servidores con certificados DH funcionen. Las claves DH en el certificado existen porque en tiempos anteriores, RSA estaba patentada pero DH no, por lo que los organismos de estandarización, en particular NIST, estaban presionando a DH como el estándar de implementación obligatoria.

Sin embargo, la realidad se encontró con eso. Nunca he visto un servidor SSL utilizando un certificado DH. Todo el mundo usa RSA. La patente RSA expiró hace una década de todos modos.

Para SSL / TLS, necesitamos 2 cosas:

1) client needs to authenticate the server.
2) client and server need to compute a symmetric session key.

Algunas formas de hacer ambas cosas:

Más común: TLS_RSA_WITH_AES _...

RSA is used for both 1 (authentication) and 2 (computing symmetric key).

Preferido: TLS_DHE_RSA_WITH_AES _... o TLS_ECDHE_RSA_WITH_AES _...

RSA is used for 1 (authentication) and for signing the DHE keys.
DHE is used for 2 (computing symmetric key).

Preferido, porque obtienes Perfect Forward Security (PFS)

No es común: DH_RSA _... (este es el DH no efímero en la pregunta de OP)

DH is used for both 1 (Authentication) and 2 (computing symmetric key).

El caso al que se refiere es el tercero ("No es común") y, como puede ver, RSA no se usa para 1 (Autenticación) ni para 2 (computación de clave simétrica), por lo que no se trata de RSA privado. llave siendo filtrada El RSA en DH_RSA puede ser engañoso, pero como mencionó Tom Leek, el Administrador del servidor proporcionará las credenciales y su clave pública DH a una CA (Autoridad de Certificación) que luego firmará la clave pública DH con la clave privada RSA de la CA.