ROWN research combines brute-force decryption of deliberately weakened EXPORT-grade ciphersuites with a Bleichenbacher padding oracle exposed by an SSLv2 server to uncover TLS session keys. Bleichenbacher oracle attacks are well known and defended-against but, ironically, the attack relies on exactly these widely implemented countermeasures to succeed.

The original Bleichenbacher attack, while mathematically brilliant, is still relatively infeasible to carry out in practice, requiring the attacker to make hundreds of thousands to millions of connections to the victim server in order to compromise a single session key. This is where the research truly shines: beautiful mathematical techniques reduce the number of connections to the ten thousands, bringing the attack down to a practical level. The researchers spent a mere US$440 on the EC2 cloud platform to decrypt a victim client session in a matter of hours.

The attack works against every known SSL/TLS implementation supporting SSLv2. It is, however, particularly dangerous against OpenSSL versions predating March 2015 (more on that below). Bottom line: if you are running OpenSSL 1.0.2 (the first, no-letter release) or OpenSSL 1.0.1l or earlier, you should upgrade immediately.

The DROWN attack is nuanced and non-trivial to implement, so we will likely not see immediate exploitation. But, once implemented, the effects are chilling. DROWN attackers can decrypt sessions recorded in the past. All client sessions are vulnerable if the target server still supports SSLv2 today, irrespective of whether the client ever supported it. There is, however, a silver lining. Only plain RSA handshakes are directly vulnerable - forward-secure sessions can perhaps be compromised by a powerful man-in-the-middle attacker, but all passively recorded forward-secure sessions remain secure.

Two devastating practical findings make DROWN much more impactful than it ever should have been. First, it is surprisingly common for services to share keys. DROWN can target your HTTPS server even if only your email server supports SSLv2, so long as the two share the same private key. While 11% of HTTPS servers with browser-trusted certificates are directly vulnerable to DROWN, another whopping 11% fall victim through some other service (most commonly SMTP on port 25).

Second, in the OpenSSL security releases of March 2015, we rewrote a section of code, which coincidentally fixed a security bug (CVE-2016-0703). This bug, if present in the server, makes the DROWN attack run in just a few minutes on, well, our laptops. This reduced complexity could lead to successful real-time man-in-the-middle attacks, hijacking a session even if the client and the server would otherwise negotiate a forward-secure Diffie-Hellman ciphersuite. Much to our surprise, DROWN scans found over 4 million HTTPS servers that, almost a year later, are still unpatched. In the wake of Heartbleed, the world saw a surge of upgrades but the awareness appears to have dropped. Thus, while the following FAQ will guide you through defending your services against DROWN, we encourage you to upgrade to OpenSSL latest even if you’re not vulnerable, and keep doing so regularly upon every security release.