¿Puede un administrador no confiable descifrar el tráfico HTTPS en Linux sin la clave privada del servidor?

La respuesta es depende , pero la regla general es que un administrador puede leer casi todo en su propio host. Tiene razón en un punto: si el protocolo utiliza DHE, Wirehark o cualquier otro analizador de red no se puede usar para descifrar los intercambios de red.

¡Pero en un punto en el host, el SSL será descifrado para que el servidor pueda procesar las solicitudes! Dependiendo de la aplicación, un administrador podría configurar el sistema de registro a un nivel que registre todas las solicitudes con su origen de IP. O podría configurar el servidor frontal apache o nginx para desviar todo a un archivo de registro si es relevante para la arquitectura del servidor. O podría agregar un filtro en la aplicación web para un registro extenso, si la arquitectura proporciona un mecanismo de filtrado. Como todo lo que ocurre después del descifrado SSL, todo estará en texto sin formato.

Por supuesto, si el servidor de aplicaciones realiza su propio proceso SSL, y solo existe en forma compilada y el malvado administrador no tiene conocimiento de su configuración o la pila completa de aplicaciones no proporciona el registro, el administrador solo podrá para examinar la memoria del proceso para encontrar partes interesantes que es poco probable que sean utilizables. Pero las arquitecturas comunes proporcionan un registro configurable precisamente para permitir que los equipos de administradores y desarrolladores comprendan qué sucede cuando las cosas salen mal.

Como regla general, no puede confiar más en un servidor de lo que puede confiar en sus administradores.

Cuando se inicia el protocolo de enlace SSL, el primer paso es que el servidor se autentique 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 se usa para una sesión significa que cuando se cierra la sesión, no se puede usar la misma clave para cifrar el tráfico de otra sesión.

Ahora el problema es que SSL a menudo usa conjuntos de cifrado RSA en los que la clave de sesión se deriva de una clave privada. Por lo tanto, la clave de la sesión se puede calcular en el futuro si se conoce el privado 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. Además, la clave de la sesión no es generada por el cliente & ni derivado de clave privada. La clave de la sesión no está encriptada / desencriptada / transmitida