SSL 2.0 no es una vulnerabilidad; es un protocolo que contiene vulnerabilidades estructurales y, como tal, no debería estar permitido.
Hay un RFC que dice eso y enumera las principales deficiencias conocidas en SSL 2.0:
SSL version 2.0 [SSL2] deficiencies include the following:
o Message authentication uses MD5 [MD5]. Most security-aware users
have already moved away from any use of MD5 [RFC6151].
o Handshake messages are not protected. This permits a man-in-the-
middle to trick the client into picking a weaker cipher suite than
it would normally choose.
o Message integrity and message encryption use the same key, which
is a problem if the client and server negotiate a weak encryption
algorithm.
o Sessions can be easily terminated. A man-in-the-middle can easily
insert a TCP FIN to close the session, and the peer is unable to
determine whether or not it was a legitimate end of the session.
De los cuatro, solo el último es realmente un problema estructural serio con el protocolo. De hecho:
-
Aunque MD5 se rompe con respecto a colisiones , todavía es bastante fuerte para otros usos, incluso cómo se usa en SSL 2.0 para proteger la integridad.
-
Cuando un atacante engaña al cliente y al servidor para utilizar un conjunto de cifrado débil, el problema real no es que el atacante pueda engañar al cliente y al servidor; es que el cliente y el servidor en realidad están de acuerdo en utilizar un conjunto de cifrado débil.
-
El punto sobre el uso de la misma clave para el cifrado y la integridad tiene sentido, de nuevo, solo si el cliente y el servidor acuerdan utilizar un cifrado débil. Esto podría suceder en días anteriores debido al cumplimiento de las regulaciones de exportación de los Estados Unidos, pero todo esto ha desaparecido desde el año 2000.
-
La falta de terminación verificada es un problema cuando el SSL se usa para transmitir un protocolo donde los mensajes no se terminan automáticamente. Un caso típico es HTTP 0.9: el cliente sabe que ha obtenido el archivo completo porque el servidor cierra la conexión. Con SSL 2.0, un atacante activo puede forzar el cierre de una conexión temprana y el cliente no tiene forma de saber si este es el final del archivo genuino o un truncado malicioso.
Uno puede argumentar que con HTTP moderno, este problema ya no se aplica.
De hecho, si un cliente y un servidor usan SSL 2.0 en este momento (mayo de 2014), es probable que esto no sea un problema real (o, al menos, no sea el mayor problema de seguridad). La razón real por la cual SSL 2.0 está prohibido es que ha estado en desuso durante mucho tiempo (desde 1996 y la invención de SSL 3.0), por lo que cualquier uso de SSL 2.0 indica que parte del software involucrado tiene no se ha actualizado durante al menos tanto tiempo, y eso es un problema. SSL 2.0 es un canario glorificado.
O, dicho de otro modo, usar o incluso permitir SSL 2.0 lo revela como un administrador de sistemas descuidado, desactualizado y poco confiable.