What is DROWN (CVE-2016-0800)?

Why DROWN mattered

By 2016, most operators believed SSLv2 was a museum piece. DROWN (Decrypting RSA with Obsolete and Weakened eNcryption), assigned CVE-2016-0800, showed that museum pieces still connected to the live Internet—and that shared RSA keys could smuggle weakness from SSLv2 into modern TLS.

Large fractions of HTTPS servers were estimated to be exposed at disclosure, either directly or through another protocol on the same certificate key. The attack reframed “legacy SSL on a side service” as a first-class risk to production TLS confidentiality.

What CVE-2016-0800 actually is

DROWN is a cross-protocol attack. An adversary collects RSA-encrypted key-transport material from a TLS handshake, then queries an SSLv2 endpoint that uses the same RSA private key. SSLv2’s export-era cryptography and error behavior supply enough information to recover the TLS premaster secret, decrypting the recorded session.

RSA key exchange was already declining in favor of forward-secret Diffie–Hellman modes. DROWN accelerated that migration by proving leftover RSA key transport plus legacy SSL was a systemic liability.

How the DROWN attack works

General DROWN and special DROWN differ in cost, but both follow a cross-protocol pattern.

Attackers did not need the victim browser to speak SSLv2. They needed the operator to leave SSLv2 reachable with a reused key.

DROWN compared with related RSA and SSL failures

DROWN sits among Bleichenbacher-style RSA padding issues and other “legacy SSL still enabled” incidents.

Who was affected

Organizations were exposed when any of the following held:

• A public HTTPS server still offered SSLv2.
• SMTP, IMAP, POP, or other TLS wrappers on the same certificate still offered SSLv2.
• A forgotten appliance terminated SSL with a production certificate.
• Hosting platforms shared certificates across many customers’ legacy configurations.

Even teams who had “disabled SSLv2 on the website” could remain vulnerable through sibling services. Inventory across every listener using a key mattered more than a single SSL Labs score for the marketing hostname.

Mitigations that closed DROWN

What practitioners should do today

• Scan all ports and hostnames tied to each certificate for SSLv2; do not trust a single HTTPS check.
• Disable SSL 2.0 and SSL 3.0 on every TLS terminator you own, including mail and internal APIs.
• Eliminate RSA key-exchange cipher suites; require ECDHE (or DHE) with modern AEAD suites.
• Avoid reusing private keys across unrelated products; issue distinct certificates per service tier when possible.
• Patch OpenSSL and vendor TLS stacks; replace devices that cannot disable SSLv2.
• Monitor certificate inventories for wide key reuse that would amplify a future cross-protocol bug.
• Treat ‘legacy protocol for one old client’ exceptions as organization-wide cryptographic risk, not local IT trivia.
• Re-test after infrastructure changes—new load balancers often reintroduce ancient protocol defaults.

Lessons DROWN left for operators

DROWN proved that protocol support is a fleet property, not a per-site checkbox. Cryptographic keys are shared secrets across every service that embeds them. Leaving one obsolete handshake enabled can undermine every modern handshake that depends on the same RSA key.

It also reinforced forward secrecy as operational hygiene. When session keys are not recoverable from a long-term private key alone, entire classes of offline and cross-protocol RSA decryption attacks lose their prize.

The practical takeaway

DROWN (CVE-2016-0800) used SSLv2 RSA weaknesses as an oracle to decrypt TLS sessions that shared the same RSA private key. Disable SSLv2 on every listener, stop sharing keys with legacy SSL services, prefer forward-secret cipher suites, and assume any remaining SSLv2 endpoint is still a threat to modern TLS confidentiality.