¿Es seguro habilitar el soporte SSLv2 ClientHello?

4

Tras el ataque de POODLE, muchos sitios web han eliminado el soporte para SSLv3. Sin embargo, algunos clientes que todavía tienen un uso relativamente común a partir de mayo de 2015 aún inician el protocolo de enlace con un mensaje de Clientvello SSLv2. Por ejemplo, openssl 0.9.8, que se envía con Mac OS X 10.10, y Java 6, que también es de uso común al menos en Mac OS X.

Oracle recomienda los servidores que utilizan el JSSE para terminar SSL mantiene habilitado el pseudo-protocolo SSLv2Hello, que a su vez permite un protocolo de enlace SSLv2 ClientHello, para la compatibilidad hacia atrás con dichos clientes. (Consulte las filas de la tabla "Desarrolladores que utilizan las API de JSSE - Servidor").

Aunque los clientes que utilizan SSLv2 ClientHello son vulnerables a los ataques de degradación del protocolo, esto también se aplica a los clientes que también utilizan versiones posteriores de handshake, a menos que tanto el cliente como el servidor sean compatibles con TLS_FALLBACK_SCSV. Y mientras el servidor haya desactivado SSLv2 y SSLv3, el protocolo de enlace no podrá completarse con un protocolo inferior a TLSv1. Y sospecho que los clientes que admiten TLSv1.1 o posterior probablemente no utilicen SSLv2 ClientHello de todos modos, por lo que me parece una configuración razonable.

¿Hay algún vector de ataque conocido que haya omitido, por lo que no sería recomendable mantener activado el soporte de SSLv2 ClientHello?

    
pregunta jbyler 23.05.2015 - 01:56
fuente

2 respuestas

3

A la luz de la reciente vulnerabilidad DROWN , ahora es fundamental que desactive los protocolos SSLv2 en cualquier servidor que pueda proporcionar El atacante tiene la posibilidad de hacer apretones de manos. Ahora se considera no solo inseguro, sino muy crítico, ya que puede comprometer a otros servidores que utilizan el mismo certificado. Más información aquí y aquí .

SSLv2Hello está seguro contra él y puede usarse ya que en realidad no hace un apretón de manos completo, sino que negocia el protocolo sobre el cual se realizará el apretón de manos.

    
respondido por el Stoinov 15.03.2016 - 10:12
fuente
3

Nota: Java / JSSE no implementa SSLv2 real (solo hola), por lo que no es necesario desactivarlo. Como dice el artículo vinculado, las actualizaciones recientes deshabilitan SSLv3 de forma predeterminada, pero puede volver a habilitarlo; intenta no.

Ataques: no creo que haya ningún ataque directo desde v2Hello, pero puede haber limitaciones funcionales. Principalmente, evita el uso de extensiones, algunas de las cuales ahora son importantes o vitales: SNI puede ser necesario para hosts virtuales o similares; Es posible que se necesiten ECcurves y posiblemente sigalgs para negociar correctamente criptografía preferida o incluso utilizable. (Se necesita Renego_info en cualquier saludo de subsiguiente , pero eso debería aumentar el formato, aunque no lo he comprobado; en el inicial apretón de manos emptyRI-SCSV es suficiente y parece En su mayoría preferido de todos modos.)

Clientes: OpenSSL 0.9.8 línea de comandos s_client por defecto es v2hello, pero -no_ssl2 o más específico -ssl3 o -tls1 lo corrige; una aplicación que use cualquier OpenSSL debe seleccionar un protocolo específico o usar el método "v23" (ahora con el nombre incorrecto) para admitir un rango que puede ser explícito, excepto que en 1.0.0+ "v23" deselecciona automáticamente el protocolo SSLv2 y formato v2hello si la lista de cifrado no incluye ningún cifrado SSLv2, y la lista de cifrado predeterminada no lo hace. Java6 client v2hello se puede deshabilitar en la aplicación, si está programado para hacerlo, se puede configurar para hacerlo, o si tiene una fuente y puede cambiarla, o al menos la parte relevante de la misma, dado que muchas aplicaciones Java son en su mayoría bibliotecas más pegamento.

    
respondido por el dave_thompson_085 23.05.2015 - 23:28
fuente

Lea otras preguntas en las etiquetas