¿Debemos configurar todos los dispositivos para que nunca soliciten SSL 2.0 y rechazarlos si se ofrecen?

Con respecto a la última parte de su pregunta: no, un proxy no puede normalmente proteger un grupo de estaciones cliente de los problemas de SSLv2. En SSL / TLS , la mayoría de las veces son así:

• El cliente envía un mensaje ClientHello en el que indica el número máximo de versión de protocolo que acepta (TLS 1.0 se anuncia como "SSL 3.1").
• El servidor responde con un mensaje ServerHello que especifica la versión del protocolo que se usará realmente.
• El cliente y el servidor intercambian algunos otros mensajes, con una fuerte criptografía, resultando en un "secreto compartido" que luego se usa como clave para cifrar y descifrar datos.
• Al final del protocolo de enlace, justo antes de enviar y recibir los datos reales de la aplicación, se envían dos mensajes Finished (uno por parte del cliente, uno por el servidor) que contienen algunos datos que son un hash calculado sobre los mensajes intercambiados previamente . El servidor (resp. Cliente), al recibir el mensaje Finished del cliente (resp. Servidor), vuelve a calcular el hash esperado; al no coincidir, cierra la conexión.

Ahora veamos que pasa cuando hay un proxy. Se supone que un proxy HTTP debe manejar solicitudes y respuestas HTTP. SSL no es un protocolo de solicitud-respuesta; Se espera y proporciona un túnel bidireccional. Entonces, se ha diseñado algo especial en HTTP (especificado en RFC 2817 , sección 5): el cliente envía un pedido CONNECT al proxy, indicándole que reenvíe todos los bytes de datos subsiguientes en ambas direcciones.

Por lo tanto, incluso en presencia de un proxy HTTP, el criptográfico todavía ocurre entre el cliente y el servidor. El proxy verá los mensajes de protocolo de enlace, pero (ese es el punto importante) no puede modificarlos, ya que eso estropearía los cálculos de hash para los mensajes Finished : el cliente y el servidor no habrían visto los mismos mensajes exactos de handshake, calcularían hashes distintos y habría desajustes con los mensajes Finished . En particular, si el cliente envía un ClientHello que indica que es compatible con SSLv2 (es decir, un ClientHello que usa el formato SSLv2, mientras sigue escribiendo en él "Admito hasta 3.1"), el proxy no puede cambiarlo.

Nota: en el protocolo SSLv2, el protocolo de enlace no tiene mensajes Finished . Entonces, un atacante que podría interceptar ambas direcciones (el proxy está en una posición ideal para eso) podría secuestrar un ClientHello en formato SSLv2 y cambiar la "versión máxima admitida" de 3.1 a 2.0. Esto puede forzar a los clientes y servidores compatibles con SSLv2 a utilizar SSLv2, incluso si ambos admiten SSLv3 +. Esto se llama "versión rollback attack". La especificación TLS 1.0 incluye una solución que bloquea ese ataque (sección E.2).

Arriba escribí "normalmente". Hay una cosa extraña que el proxy puede hacer en algunos casos. A saber, el proxy "ataca" la conexión, en un verdadero man-in-the-way-way . Esto requiere que el proxy produzca en el acto un certificado de servidor falso, con una CA ad hoc incrustada; el certificado raíz correspondiente debe haberse instalado en el cliente (es decir, no se preocupe, su proxy ISP no puede imponerle eso).

Tales proxys de secuestro existen; Este truco se usa para aplicar técnicas de filtrado agresivo en el contenido intercambiado (también es algo mal visto, porque se basa en romper ligeramente los cimientos de la seguridad SSL). Un proxy de secuestro puede teóricamente realizar un SSLv2 con el cliente y un SSLv3 + con el servidor deseado, en efecto "protegiendo a varios clientes de SSLv2".

En la práctica , el software que conoce SSLv2 pero no SSLv3 es bastante raro; En el caso de los navegadores web, esto nos remonta a mediados de los noventa. Así que, en general, puede prohibir totalmente SSLv2 de todas sus configuraciones, y las cosas funcionarán bien.

Con respecto a las prácticas aceptadas en la industria:

(de enlace )

  

"SSLv2 ha quedado en desuso y ya no se recomienda. Tenga en cuenta que ni SSLv2 ni SSLv3 cumplen con el estándar FIPS 140-2 de EE. UU., que regula los módulos criptográficos para uso en sistemas de información federales. Solo el protocolo TLS (Seguridad de la capa de transporte) más reciente cumple con los requisitos de FIPS 140-2. Además, la presencia de un servicio solo SSLv2 en un host se considera una falla por el estándar de seguridad de datos PCI (industria de tarjetas de pago) .   Tenga en cuenta que esta vulnerabilidad se notificará cuando el servidor remoto sea compatible con SSLv2 independientemente de si también se admite TLS o SSLv3. "

La compatibilidad con versiones anteriores es una de esas cosas que debemos exigir que desaparezca. Cada CISO / CSO en cada compañía debe decirle a los proveedores de productos que mueran en un incendio si admiten SSL 2.0, WEP, etc.

Probablemente. Eso es lo que la distribución de Ubuntu comenzó a hacer hace 2 años, y está terminando ahora. Vea algunos de los problemas: enlace y vea la discusión reciente en la lista de correo: enlace

SSL 2.0 tiene limitaciones de seguridad. Definitivamente recomendaría rechazar todas las conexiones SSL 2.0. Cita: enlace (Sección 2)

Creo que depende de nosotros (la profesión de la seguridad) hacer que esto suceda, por ejemplo:

Si realizamos una auditoría de TI, debemos asegurarnos de que el comité de auditoría vea un ROJO cuando exista SSL v2

Si estamos trabajando con desarrolladores web, debemos dejar claro que su software no será aceptado a menos que use al menos SSL v3, o idealmente TLS

Si estamos administrando proyectos, debemos fallar a cualquier proveedor que intente vendernos software que usa SSL v2

NOSOTROS somos los que necesitamos informar a los compradores / desarrolladores / gerentes de proyecto / CEOs que les perjudicará si se usa SSL v2, pero debemos hacerlo en lenguaje comercial. El PCI DSS es muy útil a este respecto ya que puede obligar a los proveedores de servicios de tarjeta a mejorar, y esperamos que podamos usarlos como ejemplo para persuadir a otras organizaciones.