¿Puede un servidor HTTPS filtrar accidentalmente su clave privada?

  

¿Hay casos conocidos de sitios web HTTPS que pierden la clave privada de su certificado SSL?

Sí: el error Heartbleed involucraba pérdidas de memoria en el servidor HTTP, de manera que:

  

Nos atacamos desde afuera, sin dejar rastro. Sin   Usando cualquier información privilegiada o credenciales que pudimos robar   de nosotros mismos, las claves secretas utilizadas para nuestros certificados X.509, ...

Aparte de errores como ese,

  

¿Es incluso técnicamente posible que un administrador de un sitio web malo pueda   configurar mal un sitio para enviar la clave privada como parte del certificado   cadena?

Claro. Si especifica el archivo incorrecto en, por ejemplo, SSLCertificateChainFile entonces Boom! Ahí va la clave privada.

Como @duskwuff señala en los comentarios, hay protecciones contra esto. Ni Apache ni NGINX enviarán una clave PEM que se incluye en un archivo de certificado; lo eliminarán en silencio (lo cual, estoy dispuesto a apostar, es una protección establecida después de una serie de eventos en los que las personas hicieron lo que sugerí que podría funcionar).

Otras configuraciones erróneas, como la raíz web incorrecta combinada con permisos sueltos o privilegios excesivos del servidor web, también filtrarán la clave, pero esas configuraciones erróneas son extremas y mundanas (por ejemplo, realmente tienes que estar intentando romper cosas tan mal) .

No se recomienda hacerlo.

Sí, a través de configuraciones erróneas o configuraciones incorrectas hasta ahora desconocidas. No repetiré el contenido de la respuesta de @gowenfawr.

Cabe mencionar, aparte, que hay una serie de posibles errores de configuración que no filtran directamente la clave, pero podrían permitir que un atacante descifre partes de la comunicación. Parte del trabajo hacia TLS 1.3 tiene como objetivo mitigar esto mediante la eliminación del soporte para ciertos cifrados y otras configuraciones potencialmente inseguras ( enlace ).

Del mismo modo, hay otras cosas que pueden causar la pérdida de la confidencialidad; como la vulnerabilidad SSL v2 conocida como DROWN ( enlace ) donde se sabía que SSL v2 era inseguro pero muchas instalaciones lo dejaron habilitado por razones de compatibilidad.

Aunque no es lo ideal, esto llevó a la posibilidad de extraer la clave de sesión de un servidor que usaba las mismas claves o certificado pero que ejecutaba SSL v2 a través de un oráculo de relleno, incluso exponiendo el contenido de los servicios de TLS 1.2 utilizando el mismo Certificado (después de observar una serie de conexiones entre la víctima y el servidor).

  

DROWN muestra que el mero hecho de admitir SSLv2 es una amenaza para los servidores y clientes modernos. Permite a un atacante descifrar las conexiones TLS modernas entre clientes y servidores actualizados mediante el envío de sondas a un servidor que admite SSLv2 y utiliza la misma clave privada.

En cuanto a la pérdida directa de la clave, también puede entregar su clave privada en un servidor web mal configurado, o mediante un problema de recorrido de directorio (o similar)

  

¿Hay casos conocidos de sitios web HTTPS que pierden la clave privada de su certificado SSL?

Estrictamente hablando, una clave privada debe tener permisos dr-------- , con root:root . Por lo tanto, solo el usuario root puede leer el certificado. Si esto está mal configurado y el servidor web tiene acceso a la clave privada, en algunas circunstancias, como el servidor web, se ve comprometido. Entonces aquí pudimos ver la clave privada "filtrada", involuntariamente por el servidor web. Esto, por supuesto, se aplica a cualquier programa que tenga acceso de lectura a la clave privada.

  

¿Es técnicamente posible que un administrador del sitio web incorrecto configure incorrectamente un sitio para enviar la clave privada como parte de la cadena de certificados?

Por la configuración, lo hice con Apache 2, no! Por lo tanto, una de mis configuraciones de servidor web implica:

    SSLCertificateFile /etc/apache2/ssl/safesploit.com.cert.pem
    SSLCertificateKeyFile /etc/apache2/ssl/safesploit.com.key.pem
    SSLCertificateChainFile /etc/apache2/ssl/fullchain.pem

Entonces, si bien entiendo su preocupación con respecto a un "administrador incorrecto" que coloca la clave privada dentro de la cadena completa, simplemente no es posible dentro de la vainilla de Apache 2, a menos que Apache haya sido modificado para aceptar este tipo de configuración.

Para contexto:

• Claves públicas -r - r - r-- raíz raíz
• Claves privadas -r -------- raíz raíz

No hace mucho descubrí una falla en Traefik donde un punto final de la API estaba filtrando la clave privada para su certificado SSL (CVE-2018-15598).

enlace