¿Cuáles son los riesgos de proporcionar SSLv2 para compatibilidad de dispositivo adicional?

El área en la que todas las demás respuestas parecen faltar es que la seguridad relativa (o la falta de la misma) de usar SSLv2 en términos prácticos depende del modelo de amenaza del entorno en el que se utilizarán.

Entonces, todos estarían de acuerdo en que SSLv2 es un protocolo débil (más detalles técnicos del inimitable Mr Leek aquí . Básicamente, un atacante con MITM tendrá más placer al atacar una conexión hecha con SSLv2 y, además, cuando use sistemas de cifrado más débiles, un atacante que puede ver el tráfico en una conexión podría descifrarlo más fácilmente. En cualquier caso, es justo decirlo Como esto aún no es un ataque de baja gama, los ataques MITM en SSL no son triviales de ejecutar y descifrar incluso cifrados relativamente débiles requiere un poco de esfuerzo. Bien dentro de los niveles de ataque de los estados nacionales, pero no en general en el ámbito de lo informal o lo bajo. atacar a los atacantes

Además de esto, tenemos DROWN, pero el punto clave es que solo se aplica cuando otro servidor usa la misma clave privada que la que ejecuta SSLv2.

Entonces, ¿dónde nos deja eso, de vuelta con su modelo de amenaza? ¿Quiénes son los atacantes que podrían querer comprometer su sistema?

Si nos fijamos en profesionales de alto nivel o en un estado nacional, es justo decir que SSLv2 no debería estar en las tarjetas de ninguna manera, ya que es probable que los atacantes puedan explotar las debilidades que tiene (

Sin embargo, si sus inquietudes se centran más en que los atacantes informales o de bajo nivel puedan acceder fácilmente a los datos en tránsito (tal vez se estén transmitiendo a través de una red inalámbrica que tiene otros usuarios), entonces, de manera realista, no creo que esté Es probable que se vea comprometido a través de un ataque a SSLv2

Probablemente, el mayor riesgo práctico para la empresa en esos escenarios es que, desde un punto de vista de cumplimiento, esto no se verá bien, y además, si obtiene un asesor de seguridad, lo señalará como un riesgo ...

Fuera de su problema SSLv2, desde una perspectiva de seguridad del mundo real, es probable que esté mucho más preocupado por las posibles vulnerabilidades en el software que opera en estos dispositivos, dado que parece que no podrá obtener parches de seguridad para ellos ...

  

SSL 2 quedó en desuso en 2011

No estaba en desuso, estaba totalmente prohibido , lo cual es una gran diferencia. Vea también ¿Cuál es la diferencia entre SSLv3? ¿Desaprobado y SSLv2 prohibido?

  

Sin embargo, muchos dispositivos se fabrican antes de 2011 y aún están en uso hoy en día

TLS 1.0 se definió en 1999 y estuvo disponible en las principales pilas de TLS (incluyendo openssl) desde este momento. No soportarlo ya no era una opción en 2011.

  

si un servicio de red bien diseñado proporciona compatibilidad con SSL 2

Es un tipo de afirmación contradictoria: bien diseñado versus con compatibilidad SSLv2. Tener un dispositivo SSLv2 en la red no solo es inseguro debido al protocolo SSLv2 en sí, sino también porque es muy probable que cualquier dispositivo antiguo que no pueda hablar mejor que SSLv2 también quiera usar sistemas de cifrado débiles . / p>

  

Si no se proporciona SSL 2, el servicio será completamente inaccesible para una gran parte de los dispositivos (30 ~ 40%) que, de lo contrario, son perfectamente funcionales.

Dependiendo del entorno, puede proteger dichos dispositivos agregando un poco de software en la parte frontal para que estén disponibles con mejores protocolos y cifrados.

  

Un ejemplo sería un servidor de correo electrónico corporativo para las comunicaciones diarias.

Si este servidor solo admite SSLv2 debe ser tan antiguo como que tiene muchas otras vulnerabilidades . TLS 1.0 ya estaba disponible con Windows XP.

  

¿Cuáles son exactamente los riesgos de aceptar conexiones SSL 2 en el servidor?

Si bien es malo tener SSLv2, es malo tener SSLv2 además de otros protocolos. Consulte DROWN attack para obtener detalles sobre cómo la disponibilidad de SSLv2 puede ayudar a descifrar las conexiones cifradas correctamente.

En resumen:
Si todo esto se hace dentro de una red restringida en la que no tiene actividad maliciosa, el uso de SSLv2 probablemente sea perfectamente seguro, como lo sería un texto simple. Pero tan pronto como tenga la posibilidad de que alguien ataque la red, tendrá que lidiar con los problemas causados por la versión SSL insegura ( DROWN ) y la antigüedad de la pila de SSL ( cifrados débiles ) y también en los problemas generales de software (es decir, software obsoleto y probablemente vulnerable ).

  

¿Qué tan inseguro sería, hoy, si un servicio de red bien diseñado ofrece compatibilidad con SSL 2?

extremadamente inseguro , como lo mencionaron otros. Si los datos realmente no son importantes como afirma, y es absolutamente necesario que admita esos dispositivos obsoletos, sería mucho mejor permitir solo las conexiones TLS seguras con el 60% de sus clientes actualizados, y utilizar la conexión de texto simple para otro 40% que sería inseguro de todos modos.

De esa manera, cuando se comprometan las conexiones, solo tendrá un 40% del daño para la limpieza ... Las bonificaciones adicionales es que habrá una mejor iniciación para actualizar los dispositivos antiguos ya que las personas no (erróneamente) pensarán que hay es "al menos algo de seguridad con SSL2" (no hay).

  

EDITAR: Esta no es una pregunta sobre cómo SSLv2 es inseguro o por qué no se debe usar. Se trata del riesgo empresarial asociado con proporcionar SSLv2 como un protocolo adicional compatible para la compatibilidad de dispositivos. Los dispositivos en cuestión son:

     

1. Perfectamente funcional.
  
2. Solo es compatible con SSLv2. No hay posibles rutas de actualización de software ya que estas no son computadoras.
  
3. La única otra alternativa en estos dispositivos es una transmisión de texto simple.
  
4. Representa una mayoría (o una parte no despreciable) de los dispositivos que utilizan el servicio.
  

Estoy evaluando si reemplazar todos los dispositivos o continuar usándolos, pero de una manera relativamente insegura. Por lo tanto, es una decisión de gestión de riesgo empresarial. Sin embargo, primero debo entender los riesgos comerciales de proporcionar SSLv2.

Hay dos riesgos empresariales:

1. Puede exponer a otros clientes (TLS) a ataques DROWN (que han sido bien cubiertos por otras respuestas, por lo que no los repetiré aquí).
2. Puede hacer que sus usuarios crean erróneamente que sus datos son más seguros de lo que serían si se transmitieran en texto sin formato.

El texto simple en realidad sería más seguro porque eliminaría (1) y mitigaría (2) (en la medida en que los usuarios saben que está usando texto sin formato).

(Técnicamente, montar un ataque contra una sesión de texto simple sería más sencillo que atacar SSLv2. Pero su modelo de amenaza en general no debería asumir que el adversario es perezoso, por lo que no podemos considerar SSLv2 como más seguro )