Bulletproof TLS Newsletter

Bulletproof TLS Newsletter is a free periodic newsletter bringing you commentary and news surrounding SSL/TLS and Internet PKI, designed to keep you informed about the latest developments in this space. Received monthly by more than 50,000 subscribers. Written by Hanno Böck.

DROWN attack shows danger of supporting old SSL v2 protocol

A team of cryptographers has presented new attacks against TLS encryption. Named DROWN (short for Decrypting RSA using Obsolete and Weakened eNcryption), the attack adapts an old vulnerability, originally discovered by the cryptographer Daniel Bleichenbacher in 1998, and applies it to SSL v2. Although this protocol version has been officially deprecated for many years the attack is still feasible for more than a third of the HTTPS hosts on the Internet. Crucially, even though the flaw is in SSL v2, the attack can be used against any TLS protocol version that uses the same RSA server key. Even clients that do not support SSLv2 at all are at risk.

Bleichenbacher's attack from 1998 refuses to go away

The Bleichenbacher attack is a so-called padding oracle and works against the RSA encryption mode PKCS #1 1.5. If an attacker is able to manipulate an encrypted message and get a server to tell her whether the decryption resulted in a malformed message, she can use this information leak to decrypt the ciphertext. The original attack was presented at the Crypto 98 conference and is also known as the Million Message Attack. Although the attack is now 18 years old, variations of it affecting modern software are still found on a regular basis.

The 1998 attack shouldn’t be confused with another attack Daniel Bleichenbacher developed in 2006, which affects RSA signatures. Both attacks continue to be used against software; the most prominent discovery in recent years was the BERserk attack.

Originally the Bleichenbacher attack has been applied to SSL v3 and countermeasures have been implemented. The DROWN attack now adapts the Bleichenbacher attack to SSL v2. This ancient SSL version was developed by Netscape in 1995 and quickly replaced by its successor, version 3. Even back then it was clear that the old protocol suffered from severe weaknesses. Today, modern browsers no longer support SSL v2, but it remains popular server-side.

A number of properties of the old protocol are crucial for the attack to work. SSL verifies the correctness of the handshake via the FinishedMessage. In SSLv2 the FinishedMessage is implemented in a different and insecure way and doesn’t fully protect the handshake. Additionally, SSL v2 supports a number of weak cipher suites (especially the export ones), which make the attack much easier.

With these weaknesses of the old protocol the researchers were able to design an attack that observes some TLS connections and then uses SSL v2 to attack them. Statistically, only one in about 1,000 TLS connections can be exploited. These connections must full handshakes (no session resumption) that use the RSA key exchange. When an active attack is on option, injecting some JavaScript code into the victim’s browsers can be used to collect the necessary TLS connections in seconds.

Once the required TLS connections are available, the attacker needs to submit around 40,000 SSL v2 connections to the target server to perform the Bleichenbacher attack. Then, in the final step, the attacker needs to brute force symmetric keys for the SSL v2 connections. This is the most costly part of the attack. However by using an optimized GPU implementation running on Nvidia GPUs the attack costs can be brought down to take 8 hours and cost $440 on Amazon EC2 instances. Further optimizations are possible.

OpenSSL bugs make attack easier

This attack described so far is already quite devastating, but two bugs in OpenSSL allow for variants that are even easier. All OpenSSL versions older than March 2015 contain a bug in the SSL v2 code that allows a significantly more efficient variant of the Bleichenbacher oracle. This attack reduces the computational costs to only seconds, even on a general purpose computer. An attacker still needs to open 10,000 connections to the SSL v2-enabled host, but given a fast server (or multiple servers) these can also be performed very quickly. Therefore this attack is fast enough to be executed live and used to perform Man-in-the-Middle (MITM) attacks against TLS connections, and even when the server doesn’t even support the RSA key exchange. The bug was fixed with a patch that intended to close another unrelated vulnerability (CVE-2015-0293). Back then the importance of that fix was not recognized.

A crucial precondition for the attack is that the SSL v2-enabled server supports weak export ciphers with 40 bit keys. Theoretically the attack also works with DES ciphers, but this significantly increases the costs. A bug in OpenSSL that was fixed in the last security update (mentioned in our February Newsletter) allowed a client to force-select SSL v2 cipher suites that the server was not even configured to support. Therefore even if a server doesn't announce the 40 bit export cipher suites an attacker may still be able to exploit them.

QUIC

Finally the researchers presented a variant of the attack against the QUIC protocol. QUIC is an experimental new protocol developed by Google (and supported in Chrome) with the intention to replace the combination of TCP and TLS. The properties of QUIC allow an attacker to impersonate a server if it is able to forge a single signature from the server's private key. As an RSA signature works just like an RSA decryption the same oracle method can be used to do that. Most notable here is that this attack works against servers that don't support QUIC at all. A QUIC connection can be initiated by a server over an unprotected HTTP connection. Due to several constraints this QUIC attack is significantly more expensive, the researchers estimate costs of over $9 million in EC2 resources.

For now Google disabled QUIC connections in Chrome for hosts that are not on a whitelist. In the future they will update the protocol to remove the vulnerability.

SSL v2 remains a problem

All attack variants rely on servers offering the old SSL v2 protocol. Notable is that the attack doesn't need to be performed on the same protocol or even on the same server. If the same private RSA key is used for different protocols or even with different certificates the attack remains possible. For example a HTTPS server without SSL v2 is vulnerable if there is an SMTP service using the same RSA key. SMTP is especially vulnerable here, because often mail server operators tend to configure them with support for deprecated protocols and algorithms. The thinking is that any encryption is better than no encryption. The DROWN attack shows that this kind of thinking is dangerous and carries risks.

The DROWN authors have carried out Internet-wide scans to estimate the number of vulnerable hosts. Among HTTPS hosts with trusted certificates 10% are directly vulnerable, but due to key reuse on other hosts or protocols, the numbers goes up to 22%. Among all HTTPS hosts 17% were vulnerable directly, 33% indirectly. The authors have scanned the ports for HTTPS (443), SMTP (25, 465, 587), POP3 (110, 995) and IMAP (143, 993). It should be noted that scanning additional ports and protocols (XMPP, FTP, and others) may lead to even more vulnerable hosts.

The conclusion for server operators is obvious: SSL v2 needs to be disabled everywhere, without exception. But, this has always been the case, given that we’ve known about the various SSL v2 vulnerabilities for more than 20 years now. More recently, disabling SSL v2 is the recommendation of RFC 6176, published in 2011. This RFC explicitly specifies that all compliant servers and clients must not support SSLv2 connections. The large number of vulnerable hosts shows that best practices aren't widely applied.

The DROWN attack is one of many recently discovered attacks that exploit old, weak variants of TLS and SSL. It reminds of the dangers of weakened and old encryption, just like FREAK, Logjam, SLOTH, POODLE and many others before. The most surprising aspect of DROWN is its cross-protocol nature. Even protocols that aren't supported by one side of a TLS connection may introduce risks. It also highlights the danger of key reuse. If the same key is used in different protocols with different properties unexpected cross-protocol attacks may be possible.