New TLS decryption attack affects one in three servers due to legacy SSLv2 support

Security researchers have discovered a new weakness that could allow attackers to spy on encrypted communications between users and one in three HTTPS servers.

The problem exits because many HTTPS servers still support the old and insecure SSL (Secure Sockets Layer) version 2 protocol. SSLv2 was superseded by SSLv3 in 1996, but only officially deprecated in 2011. SSLv3 was replaced, too, by the more modern TLS (Transport Layer Security) versions 1.0, 1.1 and 1.2.

SSLv2 should never be used for encrypted communications. However, security professional didn’t see support for it in server configurations as posing a security threat until now, because modern browsers and other TLS-capable clients wouldn’t use it.

But a team of security researchers has shown that premise to be incorrect.

In a newly released research paper, they showed that if an HTTPS server supports SSLv2, an attacker can exploit it to decrypt intercepted connections from its clients even if those connections are using the latest and most secure version of the TLS protocol.

Their attack, dubbed DROWN (Decrypting RSA with Obsolete and Weakened eNcryption), has several prerequisites, but is quite practical. First of all, the targeted HTTPS server needs to either support SSLv2 itself or to share its private key with another server that does so — for example, an email server.

It’s quite common for organizations to use the same private key or certificate for TLS implementations on both Web and email servers.

The attacker also needs to be in a position to observe several hundred TLS connections between a victim and a vulnerable server. They can do this by monitoring connections over a long period of time or by using malicious JavaScript to force the user’s browser to repeatedly establish connections in the background with the targeted website.

Furthermore, the observed connections need to use the RSA key exchange algorithm during the handshake, but this shouldn’t be a problem for attackers because RSA is still the most popular key exchange method in TLS implementations.

Once the attacker has the captured connections, he needs to connect to the server over the SSLv2 protocol and send specially crafted handshake messages that contain modifications of the RSA ciphertext copied from the client’s TLS connections. These probes will fail, but the way the server responds to them will leak information about the secret keys used for the victim’s TLS connections.

In the worst case scenario, an attacker would need to perform roughly 40,000 probe connections and 2^50 computations in order to decrypt one out of 900 observed TLS connections. Running the computations for the attack on Amazon’s EC2 cloud computing platform would cost about US440,ドル the researchers estimated.

Establishing 40,000 HTTPS connections with a server might sound like a large number, but it’s not. In tests with an Apache 2.4 server, the researchers completed 10,000 HTTPS requests in under 10 seconds.

The attack is significantly easier to pull off against servers that use a version of the OpenSSL library that’s vulnerable to two known flaws.

One of the vulnerabilities is tracked as CVE-2015-3197 and allows a DROWN attacker to connect to the server using disabled SSLv2 cipher suites, if support for SSLv2 itself is enabled. This vulnerability was patched in OpenSSL versions 1.0.1r and 1.0.2f, released on Jan. 28.

The second vulnerability CVE-2016-0703 greatly reduces the time and cost of carrying out the DROWN attack and stems from a bug that was patched in OpenSSL 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf back in March 2015, before that flaw’s implications were understood and reported to the OpenSSL project.

For servers that are vulnerable to CVE-2016-0703, meaning they last updated their OpenSSL library before March 2015, the DROWN attack can be carried out in less than a minute using a single PC.

The researchers scanned the Internet for vulnerable servers that accept SSLv2 connections over ports associated with SSL/TLS communications: port 443 (HTTPS), port 25 (SMTP with STARTTLS), 110 (POP3 with STARTTLS), 143 (IMAP with STARTTLS), 465 (SMTPS), 587 (SMTP with STARTTLS), 993 (IMAPS) and 995 (POP3S).

They found that 17 percent of all HTTPS servers were directly vulnerable to the generic DROWN attack version. Furthermore, 25 percent of SMTP with STARTTLS servers, 20 percent of POP3S and IMAPS servers and 8 percent of SMTPS servers were vulnerable.

They also found many HTTPS servers that don’t support SSLv2 directly, but share the same private key with other Web or email servers that do support it. This makes those non-SSLv2 servers vulnerable too, raising the overall percentage of affected HTTPS servers to 33 percent.

Fortunately, vulnerable servers don’t need to replace their certificates, because DROWN doesn’t expose their long-term private keys. Instead, the attack only exposes the secret keys negotiated by clients and servers for specific sessions.

It’s still a big problem because decrypting even a single session could expose a user’s log-in credentials, session cookies and other personal and financial information. However, the attacker would need to execute the DROWN attack for each user.

Server administrators need to ensure they have disabled support for SSLv2 on their servers. The researchers have provided instructions on how to do that for some of the most common TLS libraries and Web servers.

Administrators should also ensure that even if a server doesn’t support SSLv2, its private key is not reused on other servers that might. The researchers released a test tool that determines if a server is vulnerable and is affected by key reuse.

An estimated 25 percent of all HTTPS-enabled websites in Alexa’s top million traffic list are vulnerable. This includes popular sites like yahoo.com, weibo.com, 360.cn, alibaba.com, buzzfeed.com, weather.com, flickr.com, and dailymotion.com.