DROWN (Decrypting RSA with Obsolete and Weakened eNcryption)

DROWN was disclosed in March 2016 by an academic research team. SSLv2 had been obsolete for many years, but many servers still accepted it, and its export-grade ciphers and handshake flaws turn it into a Bleichenbacher-style padding oracle for RSA. An attacker records TLS connections that used RSA key exchange, then sends many crafted SSLv2 handshakes to any server holding the same RSA key and uses the responses to decrypt the recorded TLS session. The TLS server itself does not need to support SSLv2; sharing a key or certificate with a server that does is enough.

Why it matters

DROWN showed that a weak protocol on one port or host can compromise strong TLS elsewhere: a mail server with SSLv2 enabled could expose a web server that never offered it, if both used the same certificate and key. At disclosure, a large share of HTTPS servers was vulnerable, mostly through such key reuse. Mitigation: disable SSLv2 everywhere (OpenSSL removed SSLv2 support in version 1.1.0), avoid sharing private keys between services with different configurations, and prefer ECDHE key exchange, because DROWN decrypts only sessions that used RSA key exchange.

Example

Check every host and port that uses the same certificate, not only the website:

nmap --script sslv2 -p 443,25,465,587,993,995 mail.example.com

Common misconceptions

• My web server does not enable SSLv2, so DROWN cannot affect it. Any other server using the same RSA key, such as an old mail or VPN server, is enough.
• TLS 1.2 sessions are immune. TLS 1.2 sessions that used RSA key exchange were exactly the target; forward-secret ECDHE sessions cannot be decrypted this way.
• Replacing the certificate fixes it. Only if the new key is not shared with an SSLv2-enabled host; the root fix is disabling SSLv2.