La vulnerabilidad de POODLE explotó una debilidad en SSLv3. La nueva vulnerabilidad DROWN explota una debilidad en SSLv2. Parte de mi protección contra POODLE (para mi servidor web) fue deshabilitar SSLv3 y versiones anteriores.
Entonces, ¿ya estoy a salvo de DROWN?
Tenga en cuenta que una versión reciente de OpenSSL tenía un error ( CVE-2015- 3197 ) que permitía a un cliente negociar conjuntos de cifrado deshabilitados (como los cifrados EXPORT de SSLv2, para DROWN) incluso si estaban deshabilitados en OpenSSL en tiempo de ejecución. Asegúrese de estar actualizado (siempre es una buena idea, por supuesto, especialmente con cosas como OpenSSL) y desactive todas las versiones de SSL. No te olvides de reiniciar los procesos de tu servidor después de actualizar la biblioteca, para que recoja la nueva versión de la biblioteca OpenSSL.
Además, tenga en cuenta que el DROWN puede explotarse en servidores que albergan diferentes protocolos (por ejemplo, usar un servidor de correo electrónico para atacar una conexión HTTPS) si el otro servidor es compatible con SSL2 y utiliza la misma clave pública que su servidor web. Dado que la reutilización de claves públicas es bastante común, y como las conexiones seguras a servidores de correo electrónico (y similares) generalmente no están sujetas a tanto escrutinio como seguridad de conexión de servidor web, aún puede ser vulnerable a DROWN incluso si su web server no permite SSLv2.
POODLE es un abuso de una falla en SSL 3.0. Usted está técnicamente protegido contra POODLE si deshabilitó el soporte para SSL 3.0.
DROWN aprovecha una falla en SSL 2.0. Puede estar técnicamente protegido contra POODLE, en el sentido explicado anteriormente, y aún ser vulnerable a DROWN.
Por supuesto, SSL 2.0 tiene otros defectos y ya estaba en desuso / prohibido; Ha sido así durante mucho tiempo. El consejo para POODLE se redactó a menudo como "desactivar todo lo que es más antiguo que TLS 1.0" y esto incluye SSL 2.0, pero, honestamente, SSL 2.0 ya debería haberse desactivado, matado y su cadáver arrojado en el mar, mucho antes que POODLE. Si tuvieras que esperar a que POODLE deshabilitara SSL 2.0, entonces ya eras muy descuidado. No hay límite superior para el descuido, por lo que le recomendamos que pruebe si su servidor todavía acepta SSL 2.0. Por si acaso.
Depende.
Eres vulnerable a DROWN si CUALQUIER servidor tiene la misma clave RSA que la tuya, ejecuta SSLV2 y permite el "cifrado de exportación" de baja seguridad. Ejemplos de esto pueden ser un certificado con varios nombres alternativos o un certificado comodín.
Por ejemplo:
Deshabilitó SSLV2 y SSLV3 en su servidor web. Otro administrador de su organización, Bob comparte el mismo certificado SSL con usted, ambos firmados con un nombre alternativo y, por lo tanto, comparten la misma clave RSA. Su servidor es www.mydomain.com ejecutando https, y el servidor de Bob es email.mydomain.com, ejecutando SSL sobre SMTP.
Bob es un poco más descuidado con SSL y no deshabilitó SSLV2 en su servidor. Dado que ambos tienen la misma clave RSA, un atacante puede usar el servidor mal configurado de Bob para comprometer la seguridad SSL de su servidor correctamente configurado.
SSL Labs actualmente tiene una prueba para el ataque DROWN en su servidor de pruebas , y tienen una excelente informe sobre la vulnerabilidad .
Algunos de los puntos más destacados que ya se han tratado en otras respuestas:
... sabemos que SSL v2 es inseguro desde hace mucho tiempo, más de 20 años.
... DROWN en realidad empeora las cosas porque abusa de SSL v2 para atacar todos los demás protocolos
... la seguridad de un servidor no se puede determinar solo mirando su configuración. Para DROWN, tenemos que buscar la presencia del las claves RSA del servidor y / o los nombres de host de certificados en cualquier otro lugar.
Lea otras preguntas en las etiquetas tls