es posible descifrar HTTPS con el par (privado, público) si usa DHE?

Cuando se inicia el protocolo de enlace TLS / SSL, el primer paso es autenticar el servidor mediante una clave privada asociada al certificado del servidor. En un segundo paso, el cliente y el servidor intercambian una clave de sesión utilizada para cifrar la carga útil de la conexión. La clave de sesión utilizada para una sesión significa que cuando se cierra la sesión, no se puede utilizar la misma clave para cifrar el tráfico de otra sesión. Ahora el problema es que SSL / TLS a menudo utiliza conjuntos de cifrado RSA en los que la clave de sesión se deriva de la clave privada. Por lo tanto, la clave de la sesión se puede calcular en el futuro si se conoce el secreto subyacente.

DHE y ECDHE brindan Perfect Forward Secrecy (PFS), lo que significa que las claves de sesión no se derivan de una clave privada. Por lo tanto, el atacante no puede descifrar el tráfico incluso cuando tiene la clave privada utilizada en el protocolo de la sesión.

En DHE (no DH), las claves de sesión se calculan utilizando los números aleatorios.

Conclusión

No puede descifrar el tráfico utilizando una clave privada cuando se utiliza DHE o ECDHE.

solo para los registros: cloudflare publicó algunos buenos gráficos sobre cómo funcionan los protocolos RSA y DH:

Para resumir: no, no puedes. Este es el punto exacto de DHE . En términos pomposos, DHE proporciona perfecto secreto hacia adelante , lo que significa que el conocimiento de la clave privada del servidor permanente (el que corresponde a la la clave pública en el certificado del servidor) no es suficiente para descifrar sesiones pasadas.

Técnicamente, cuando se usa DHE, el certificado y la clave privada del servidor se usan solo para una firma : el servidor firma su clave pública DH recién generada y transitoria; El cliente verifica esa firma. Así se usa la clave privada; Sólo no para fines de encriptación. Al tener una copia de la clave privada del servidor, podría falsificar una firma falsa, lo que significa que podría hacerse pasar por el servidor; pero las firmas no ocultan datos, por lo que un ataque solo pasivo (como se propone hacer) no puede aprender nada de esa manera.

Si el servidor utiliza DHE y necesita ver los datos, debe montar un ataque activo , generalmente conocido como Ataque Man-in-the-Middle . Te haces pasar por un servidor falso; utiliza su conocimiento de la clave privada del servidor para hacerse pasar por el servidor; cuando un cliente se conecta, usted también se conecta como un cliente al verdadero servidor y retransmite los datos en ambas direcciones. El MitM descifra los datos recibidos del cliente y los vuelve a cifrar en la conexión SSL abierta con el verdadero servidor, y hace lo mismo en la dirección del servidor al cliente. De esa manera, MitM puede ver todos los datos, pero debe trabajar activamente en el momento de la conexión. No puede hacer eso después del hecho, es decir, descifrar una sesión pasada que grabó de forma pasiva. Por lo tanto PFS.