DROWN Abuses SSL v2 to Attack TLS

Ivan Ristic

Last updated on: November 3, 2022

A fascinating new research called DROWN has uncovered a previously-unknown vulnerability in SSL v2, the first ever version of SSL that was released in 1995 and declared dead less than a year later. Even though this old version of SSL is not used much these days, it continues to be supported by many servers. The especially bad aspect of this attack is that it can be used to exploit TLS, even in cases when client devices don’t support SSL v2, and sometimes even in cases when the servers don’t support SSL v2 (but use the same RSA key as some other server that does). The researchers estimate that up to 22% of servers could be impacted by this problem.

Disable SSL v2 Everywhere Now

The attack is not trivial, but can be done cheaply against high-value targets. Before you go on to learn more about it, I recommend that you first ensure your systems are not vulnerable. Fortunately, remediation is straightforward: disable SSL v2 on all servers you have. It’s as simple as that…. but I really do mean all servers. If you’ve been reusing private RSA keys (even with different certificates), disabling SSL v2 on one server is not going to help if there’s some other server (possibly using a different hostname, port, or even a protocol) that continues to support this old and crazy-vulnerable protocol version.

Impact of the Generic Attack

The attack is an extension of the 1998 Bleichenbacher attack that can be used to decrypt a ciphertext when a padding oracle exists. For more information, I suggest that you read the original DROWN research, which is very interesting indeed. However, the bottom line is that one out of every 1,000 full TLS handshakes can be decrypted, leading to the compromise of the entire TLS session (potentially many connections of data). The cost is modest—only $440 and 8 hours. (The attack can be sped up if you want to spend more money on it. There is also a much better attack against some OpenSSL versions; I describe it later in this text.) The generic attack is entirely passive, but requires that 1) RSA key exchange is used and 2) that there is an SSL v2 server configured with the same private RSA key.

The worst case is when an automated service is attacked, anything that might be carrying connection credentials. Even though you need 1,000 full TLS handshakes, you’ll get those in a matter of hours, and the credentials will be yours to do as you’re pleased.

Attacking browser sessions is going to be more difficult, because HTTPS servers typically rely on TLS session caching as a way of improving handshake performance. A bigger problem is that user sessions rarely carry credentials; in most cases you can compromise session cookies and perform account hijacking. But that’s not bad at all!

Speeding-Up the Generic Attack

I developed a slight improvement to the attack, for the cases when you don’t want to wait a lot of time to collect those 1,000 handshakes and don’t mind carrying out an active attack. It’s possible to speed things up by injecting some JavaScript into the victim’s browser (a-la-BEAST). You’re still up against TLS session caching, though. But TLS has an interesting property, in that it requires TLS sessions to be invalidated whenever an error occurs (e.g., client receives an invalid TLS record). Thus, as a MITM, all you need to do is force an error on established TLS sessions, causing a new full handshake on the subsequent connection. This way you can obtain the required 1,000 TLS handshakes very quickly.

Best Attack Variant is against Vulnerable OpenSSL Servers

The best attack variant is against servers that use a vulnerable version of OpenSSL. The recent versions of OpenSSL are not vulnerable because the exploited flaw had been patched (without knowing) in March 2015. But, if the conditions are right, the same SSL v2 flaw can be used for real-time MITM attacks and even against servers that don’t support the RSA key exchange at all.

Obsolete Crypto Is Dangerous

Once again, we realise that obsolete crypto is dangerous. For many years the argument for not disabling SSL v2 was that there was no harm because no browsers used it anyway. We heard the same thing before learning about Logjam, and also before FREAK. This approach is obviously not working. Instead, in the future we must ensure that all obsolete crypto is aggressively removed from all systems. If it’s not, it’s going to come back to bite us, sooner or later.

Show Comments (9)


Your email address will not be published. Required fields are marked *

  1. What if certificates dont have SSL on them, do we still need to get SSL disabled on the server configurations ? In the scenarios where Load balancers are used for SSL termination, do you think we should still carry out a check on server configurations ?

  2. The fact that this attack takes advantage of the target using the same private key for multiple protocols brings up the obvious question: Does Qualys plans to expand its SSL server test beyond HTTPS in the future ?
    Also, will the development version (https://dev.ssllabs.com) integrate DROWN detection soon ?

    Side question: Since this attack aims exclusively at RSA key exchange, isn’t it a good timing to drop this protocol and use EECDH/ECDSA instead ?

  3. @ATo, the development server already test for DROWN, with the help of Censys data. However, please note that the implementation is still experimental and will be further improved. (In particular, there is currently no impact on the grade, but that will be added tomorrow.)

    As for ECDSA, the main issue is that not all clients support ECDSA at this time. At the very least, an RSA+ECDSA combo is needed if you’re aiming a site at a general audience.

  4. @Ivan, you didn’t answer to the question of support for more TLS protocols than just HTTPS at SSL Labs. Two years ago you promised that feature for version 2 which we’re still expecting. Could you please explain what stops you from rolling out STARTTLS support for testing SMTP or IMAP? It’s a long expected feature, and it’s now more time than ever, especially as DROWN requires an alternative ‘channel’ for connection. Without explicit testing for it, most servers will remain unfixed, but now the whole world knows about DROWN, so this help is really needed.

    As for ECDSA, I’m not with your general statement. ECDSA is absolutely okay if you can cut off some old hair. And for most of the servers out there it’s absolutely time for that. Only those that really have to still support old Android 2.3, IE on XP, Java 6 or OpenSSL 0.9.8 clients really need a pure or mixed RSA key/certificate, all others can already change to ECDSA, and that’s definitely the way to go. Compatibility with the stone age is not the kind of thing that should be top on every one’s list.

  5. @Matthias, there is no mystery: development time is the limiting factor. Checking of other protocols would have been implemented by now, but there were so many new TLS flaws in the last 2 years; most of my dev time went on keeping up. We’ve hired someone who will start working full-time on SSL Labs. So, mid-term, there should be an improvement to the speed of development.

    1. @Ivan we are all grateful to you for providing this tool for free. I’m glad to read that it will be improved in the future. Regarding the drop of TLS for key agreement, I set the following ciphers on my server. “EECDH+AESGCM:EDH+AESGCM:EECDH+AES:EDH+AES”. Let us know if you would suggest something else.

      Also, does supporting STARTTLS on SMTP/IMAP/POP server prevent the attack ? I haven’t read the full paper (yet) but this seems not to be mentioned nor in the FAQ.

    2. Hey there. I’m looking at this now and I’ve gone through all of my services that it says are vulnerable and all seem to have SSLv2 disabled and I don’t seem to have anyway to retest so I feel it’s a false positive. Is there a test I don’t know of other than testing with the openssl client? I’ve not needed to change anything in months…