The DROWN security hole – what you need to know

Our Vulnerability of the Week Award goes to DROWN, for a cool name and an amusing logo.

The name stands for Decrypting RSA with Obsolete and Weakened eNcryption, and the logo is a cracked padlock that’s about to be swamped by a wave.

The DROWN attack works against TLS/SSL.

That’s the security protocol that puts the S-for-Secure in HTTPS, adds the padlock in your browser, and provides the encryption that most webmail services (and any well-configured corporate systems) use these days when transferring email to and from other mail servers.

“Obsolete and weakened”

If you’ve been following cryptographic news about TLS/SSL over the past year, you’ll probably smell something familiar in the mention of “obsolete and weakened encryption.”

Loosely put, DROWN depends on a cryptographic backdoor known as EXPORT_GRADE, baked into US products by law until the end of the twentieth century.

EXPORT_GRADE was supposed to make our regular communications safe enough against everyday attackers, while giving national-level organisations such as the NSA a fighting chance to crack enemy traffic, given enough time and money.

The outcome of EXPORT_GRADE had two unsurprising outcomes. (These alone ought to convince you that a #nobackdoors policy is a necessity for our security in the future!)

Firstly, EXPORT_GRADE killed off the export market for the very US companies it was supposed to protect, because foreign customers just bought foreign, full-strength products instead.

Secondly, it left us with a bunch of official legacy ciphers that are so weak (thanks to much faster computers today) that you could probably crack them yourself, using compute servers in the cloud, for not much more money than you’ve got in your wallet right now.

The problem was that when the US finally lifted the EXPORT_GRADE rules, software makers quickly got into the habit of not using the weakened ciphers any more, but often without bothering to get rid of the weak programming from their products, leaving it sitting there waiting to cause trouble.

And trouble is what happened in the end.

In 2015, TLS/SSL vulnerabilities callen FREAK and LOGJAM showed that it was possible to trick servers that still supported EXPORT_GRADE to fall back to these “backdoor” ciphers, and thus made it possible, albeit unlikely, that crooks could break into supposedly-secure TLS sessions.

The DROWN attack

DROWN does something similar, giving attackers a tiny but fighting chance of cracking individual TLS connections.

As the DROWN paper points out, the general form of this attack requires roughly 40,000 probe connections and 2⁵⁰ cryptographic computations, and would cost about $440 in cloud computing charges. For each investment of that amount of time and money, you get a 1-in-900 chance of decrypting a single TLS connection.

We’re not going to try to explain DROWN here, because the paper consists of 22 dense and technical pages, but, very briefly put, the attack works against servers that support TLS, and SSL 2, and EXPORT_GRADE ciphers.

SSL 2 is a legacy predecessor to TLS: you shouldn’t use it or even support it any more because it is known to be insecure.

Indeed, the internet standards document RFC 6176, published five years ago, “requires that TLS clients and servers never negotiate the use of SSL version 2.0.”

Nevertheless, if you can find a server that does accept both TLS and SSL 2, and also supports EXPORT_GRADE ciphers, you may very occasionally be able to eavesdrop on an encrypted session.

You can sniff data from an existing TLS connection, and then use it in a sequence of SSL 2 connections to the same server in the hope of figuring out the decryption key needed to eavesdrop on the original TLS connection.

Note that decrypting one TLS session at a time is all you can do with this attack. Unlike Heartbleed, you can’t use DROWN to retrieve secret data from the server itself, such as other people’s data, or the server’s private key.

This works because the TLS and the SSL 2 connections share the same “back end” cryptographic material, including the server’s private key.

In fact, the TLS and SSL 2 connections don’t have to be on the same server.

If you can find other servers that share the same encryption keys, you can sniff the TLS traffic on one server, and then do the SSL 2 attack against the decryption key on any of the other servers.

What this means is that if you run a service consisting of multiple servers configured identically, perhaps even across multiple sites, you could make all of them vulnerable simply by forgetting to turn off SSL 2 on just one of them.

What to do?

• Don’t allow EXPORT_GRADE ciphers on any of your servers. These “backdoor” ciphers have been legally unnecessary for more that a decade, and supporting them introduces the risk that an attacker could use 2016 computing power to attack ciphers that were deliberately chosen to be breakable more than two decades ago.
• Don’t allow SSL 2 on any of your servers. With or without EXPORT_GRADE ciphers, SSL 2 is dangerously weak for reasons listed in RFC 6176, Prohibiting Secure Sockets Layer (SSL) Version 2.0.
• Please support Sophos’s #nobackdoors position. DROWN is the third practical reminder in the space of 12 months that you can’t make the internet stronger by weakening it.

Note. The DROWN project’s website contains an online service that checks whether a named server is at risk. Be warned that this service does not actually perform any tests, but simply looks up the answer in a list that was prepared earlier. In particular, if you have just reconfigured a potentially vulnerable server, the DROWN checker is likely to leave you thinking that your fix has failed!