Today, an international group of researchers unveiled DROWN (Decrypting RSA with Obsolete and Weakened eNcryption), aka CVE-2016-0800, a novel cross-protocol attack that uses SSLv2 handshakes to decrypt TLS sessions.

Over the past weeks, the OpenSSL team worked closely with the researchers to determine the exact impact of DROWN on OpenSSL and devise countermeasures to protect our users. Today’s OpenSSL release makes it impossible to configure a TLS server in such a way that it is vulnerable to DROWN.

Background on DROWN

DROWN 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.

DROWN FAQ for OpenSSL users

Is my server vulnerable to DROWN?

It depends on your server configuration. You can only be sure that you are not vulnerable if none of your services sharing a given private key enable SSLv2. Your secure TLS-only HTTPS server is vulnerable if you expose the same key on an email server that supports SSLv2.

Apache HTTP Server users

If you use an Apache HTTP server with keys that you don’t share with any other services, and that server runs Apache httpd 2.4.x, you are not affected (because httpd 2.4 unconditionally disabled SSLv2). If the server runs Apache httpd 2.2.x, SSLv2 is supported by default, and you are likely to be vulnerable. You should ensure that your configuration disables SSLv2 (and preferably, SSLv3 too):

SSLProtocol All -SSLv2 -SSLv3

nginx users

Versions 0.7.64, 0.8.18, and earlier enable SSLv2 by default. You should similarly disable SSLv2 in your configuration:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2

Later nginx versions have safe default configurations, but you should double-check the ssl_protocols setting in your config.

Postfix users

Postfix releases 2.9.14, 2.10.8, 2.11.6, 3.0.2, released on 20/Jul/2015 and all later releases are not vulnerable in their default configuration. The below recommended TLS settings for Postfix are sufficient to avoid exposure to DROWN. Many of these are defaults in sufficiently recent releases. Nevertheless, in addition to ensuring that your Postfix configuration disables SSLv2 and weak or obsolete ciphers, you should also deploy the appropriate OpenSSL upgrade.

   # Minimal recommended settings.  Whenever the built-in defaults are
   # sufficient, let the built-in defaults stand by deleting any explicit
   # overrides.  The default mandatory TLS protocols have never included
   # SSLv2, check to make sure you have not inadvertently enabled it.
   #
   smtpd_tls_protocols = !SSLv2, !SSLv3
   smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
   tlsproxy_tls_protocols = $smtpd_tls_protocols
   tlsproxy_tls_mandatory_protocols = $smtpd_tls_mandatory_protocols

   smtp_tls_protocols = !SSLv2, !SSLv3
   smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
   lmtp_tls_protocols = !SSLv2, !SSLv3
   lmtp_tls_mandatory_protocols = !SSLv2, !SSLv3

   smtpd_tls_ciphers = medium
   smtp_tls_ciphers = medium

   # Other best practices

   # Strongly recommended:
   # http://www.postfix.org/FORWARD_SECRECY_README.html#server_fs
   #
   smtpd_tls_dh1024_param_file=${config_directory}/dh2048.pem
   smtpd_tls_eecdh_grade = strong

   # Suggested, not strictly needed:
   #
   smtpd_tls_exclude_ciphers =
        EXPORT, LOW, MD5, SEED, IDEA, RC2
   smtp_tls_exclude_ciphers =
        EXPORT, LOW, MD5, aDSS, kECDHe, kECDHr, kDHd, kDHr, SEED, IDEA, RC2

Everyone

Note that if you’re running anything but the latest OpenSSL releases from January 2016 (1.0.2f and 1.0.1r), a subtle bug (CVE-2015-3197) allows the server to accept SSLv2 EXPORT handshakes even if EXPORT ciphers are not configured. Therefore, disabling weak ciphers is not a universally reliable countermeasure against DROWN; you should really disable SSLv2 entirely.

The DROWN researchers have also set up a more precise test for vulnerable services.

Should I upgrade to the latest OpenSSL version?

In short: yes, everyone should upgrade. You can mitigate DROWN completely with a configuration change. But today’s release fixes a number of other vulnerabilities, and we cannot emphasize the importance of timely upgrades enough.

How do I know which OpenSSL version my system is running?

If you obtained OpenSSL directly from us (from https://www.openssl.org, or from https://github.com/openssl/openssl), run the following command to find out:

$ openssl version

If you are using the system OpenSSL provided with your Linux distribution, or obtained OpenSSL from another vendor, the version number is not a reliable indicator of the security status. Some third party distributions have a policy of only backporting selected security updates without changing to a newer version, to provide stability. Each distribution varies; you should install the updates provided by your vendor and contact them for questions about this or any other security issues.

Debian users can also track the security status of Debian releases, using Debian’s security tracker. All issues affecting OpenSSL can be found in the search by source package and information about DROWN will appear under the tracker for CVE-2016-0800.

Red Hat has an information page about this issue for their users.

I run an OpenSSL-based client application. Do I need to do anything?

DROWN is primarily a server-side vulnerability. However, as a matter of best practices, you should ensure that your client supports the highest current protocol version (TLSv1.2), and negotiates forward-secure ciphersuites.

You should also upgrade to OpenSSL latest. (Did we say that already?)

Does DROWN compromise my private key?

No. DROWN attacks can only target individual sessions, not the server’s key. Even if there has been a successful DROWN attack against you, there is no need to regenerate your private key, so long as you can confidently identify all services that share this key, and disable SSLv2 for them.

The OpenSSL team would like to thank Nimrod Aviram, J. Alex Halderman and the entire DROWN team for their cooperation.