Para entender la terminología: el certificado es la parte pública. Es público para que todos lo sepan, y cuando un cliente se conecta a un servidor SSL, ese certificado es una de las primeras cosas que el servidor envía al cliente. Lo que quiere decir es: cuando la clave privada no es realmente privada, ¿se puede seguir considerando SSL como "seguro"?
La respuesta es básicamente: No .
Sin embargo, hay detalles sutiles. Cuando el cliente y el servidor se comunican entre sí, acuerdan un conjunto de algoritmos criptográficos a utilizar, llamados conjunto de cifrado . Consulte el estándar para (la mayoría de) los conjuntos de cifrado definidos actualmente. Uno de los elementos de la suite de cifrado es el acuerdo clave utilizado para intercambiar el "secreto pre-maestro" de que todas las demás claves se derivan. Cuando la suite de cifrado es una suite "RSA" básica (es decir, los nombres de la suite de cifrado comienzan con " TLS_RSA "), entonces el acuerdo clave es el cifrado asimétrico básico con RSA: el cliente genera un secreto pre-maestro aleatorio, lo cifra la clave pública del servidor (de su certificado), y el servidor la descifra para recuperar el secreto maestro previo.
Cuando un atacante conoce la clave privada del servidor y simplemente escucha el canal, ese atacante también puede descifrar el mensaje del cliente, obtener el secreto maestro y descifrar todos los datos. Parece seguro decir que, en estas condiciones, queda muy poca seguridad.
Sin embargo, si el conjunto de cifrado negociado es del tipo "efímero Diffie-Hellman" (el nombre comienza con " TLS_DHE "), el acuerdo de clave real usa Diffie-Hellman con pares de claves DH públicas / privadas que se han generado aleatoriamente en el lugar. La clave privada del servidor (la que está codificada y, por lo tanto, no es muy privada) se usa solo para firmar la clave pública DH. En estas condiciones, un atacante puramente pasivo, que simplemente espía en los paquetes de datos pero no interfiere, no podrá obtener el secreto maestro previo y la conexión permanecerá segura. Esta función de DHE se llama Perfect Forward Secrecy .
Sin embargo, incluso con DHE, un atacante activo puede hacerse pasar por el servidor y montar un Ataque Man-in-the-Middle , anulando cualquier seguridad. PFS es una ventaja real solo cuando se considera el caso de un robo de clave privada ulterior , donde el atacante roba la clave privada del servidor después de que se ha producido la conexión. En ese momento, es demasiado tarde para que el atacante esté "activo", y PFS lo bloquea. Pero esta no es su situación: imagina un caso en el que el atacante ya conoce la clave privada del servidor cuando se produce la conexión. El atacante puede montar un ataque activo.
Entonces, para resumir : cuando los atacantes conocen la clave privada del servidor, la seguridad se mantiene solo contra los atacantes solo pasivos , y luego solo si el cliente y el servidor acuerda un conjunto de cifrado DHE.
(Estrictamente hablando, la seguridad se puede salvar incluso contra atacantes activos si el conjunto de cifrado es DHE y el servidor requiere un certificado de cliente y no se conoce la clave privada del cliente para el atacante. Eso es un caso de ventaja.)