¿Cuáles son las implicaciones de seguridad de habilitar un agujero SNI en un servidor web?

8

Un servidor web (digamos Apache 2.4) implementa SNI. Se configura con un certificado de comodín firmado por SHA384 de 4096 bits (* .land.org) con un nombre alternativo del sujeto (land.org). La Autoridad de certificación tiene una ruta de confianza para un certificado raíz firmado SHA-2, así como una segunda ruta de confianza para un certificado raíz firmado SHA-1. Digamos también que este servidor web implementa lo que actualmente se considera una renegociación segura.

El servidor web está configurado para un Host virtual predeterminado (wonder.land.org) con solo SSLv3 habilitado, con un certificado SSL que contiene una clave DH1024 única y todas las claves antiguas e inseguras del libro (112 bits hasta exportar cifrados, etc., de manera que incluso a Netscape Communicator le complacería). El otro host virtual es land.org con TLSv1.2 y TLSv1.0 habilitados, con cifrados de más de 128 bits y una clave DH2048 única. Los pedidos de cifrado para ambos Hosts virtuales son de mayor a menor, según las vulnerabilidades conocidas y la fortaleza del cifrado.

Bob es un usuario con un navegador moderno que admite el cifrado de curva elíptica TLSv1.2 con paranoia contemporánea. Accede a enlace a diario.

Alice es curadora de museos en el Smithsonian y utiliza un antiguo navegador web que admite el cifrado de exportación a través de SSLv3. Ella accede a enlace a diario para asegurarse de que la conexión 10BASE2 aún funciona en el 486DX2. Dado que el navegador web no es compatible con SNI, la solicitud de Alice cae a través de un "agujero SNI", devolviendo el Host virtual predeterminado (wonder.land.org), que es una página estática HTML 2.0 que indica "Su cliente web no es compatible con Server La indicación del nombre y es vulnerable a un ataque de poodle. Considere la posibilidad de actualizar la exposición de su museo. Sin embargo, su conexión a Internet sí funciona ".

Pregunta (Sí / No): ¿Este servidor web compromete la seguridad de Bob, o la seguridad propia (del servidor)? Tenga en cuenta solo las vulnerabilidades actualmente conocidas públicamente.

    
pregunta vallismortis 16.06.2015 - 03:05
fuente

1 respuesta

3

Mi intuición fue que preferiría dirigir las conexiones sin SNI a un servidor diferente (no al mismo que sirve a Bob), y por medios externos al mismo servidor. Algo así como un firewall de Inspección de paquetes profundos que realmente mira las versiones de ClientHello y la parte de SNI.

Puedo ver dos razones para que el agujero SNI no se analice en el mismo servidor:

1) Los encabezados de host e indicación del nombre del servidor TLS son características completamente diferentes en diferentes capas de protocolo, pero tienen un propósito muy similar. Debido a esto, puede que a los creadores de software de servidor no les interese interpretarlos de manera diferente, y puede ser algo difícil seguir probando que el comportamiento de seleccionar el host virtual está sucediendo en el nivel SNI de TLS, por lo que en una futura actualización Bob podría terminar en el servidor inseguro con una cookie que no debía enviarse a través de este método (o Alice podría recibir un error en lugar de una explicación relajante sobre su conexión).

2) Al mantener todos los cifrados débiles y las variaciones de protocolo en el mismo servidor, mantienes el software del servidor complicado, y posiblemente abierto para los vectores de ataque desconocidos hasta ahora de alguna manera capaces de revertir / revertir a versiones inseguras del protocolo. >     

respondido por el chexum 19.12.2015 - 01:22
fuente

Lea otras preguntas en las etiquetas