The DROWN attack

nine Team Mar 2, 2016

A new security gap in the TLS protocol SSLv2 has recently been discovered. Hackers succeeded in cracking encrypted SSL/TSL connections (HTTPS),decrypting data traffic that had been fully encrypted and getting their hands on the actual content. The problem is new only in the figurative sense because it basically involves an older TLS protocol that has been around for 18 years but is no longer used in today’s web browsers. Along with availability, security is first priority at So we’ve decided to dedicate a blog post to the topic and explain which vulnerabilities can be exploited and how we can protect our Managed Server customers and Root server operators.

What is DROWN?

DROWN stands for “Decrypting RSA with Obsolete and Weakened eNcryption”. The attack targets the now obsolete SSLv2 protocol. As mentioned, current web browsers no longer support this protocol. The last web browser to actively support it was Internet Explorer 6.x. You might be tempted to point out that this fact makes the gap irrelevant. Unfortunately, this is not the case, as many servers still support SSLv2 communications for compatibility reasons. What is unusual about this attack is that it can even threaten connections that use other protocols as well. It should be noted that the SSLv2 protocol was the very first encryption protocol to be used online on a widespread basis.

How does DROWN work?

Back in 1998 Daniel Bleichenbacher demonstrated how this type of vulnerability can be exploited using a ‘chosen’ ciphertext attack (also commonly referred to as a Bleichenbacher attack) to execute several thousand handshakes and meticulously analyse them. The attacker manipulates and in some cases sends messages that have been erroneously encrypted intentionally to a certain server. The server then responds by acknowledging these requests – including with error messages, for example, instead of simply ignoring the connection request. Using this information, the attacker can then work out the pre-master secret key. This key is essential and consists of a 46-byte random cipher that is used to generate the symmetric encryption key and authentication code, which is then encrypted using the server’s public key.

Of course, this also means that as soon as this key is known, the other types of SSL/TLS communications used today can also be decrypted since the new protocols use this same cipher. This is exactly what makes these attacks so dangerous and many servers vulnerable.

Researchers slightly modified this attack and succeeded in cracking encrypted connections. Basically, it works like this:

An attacker captures all TLS traffic. These encrypted communications may contain user names and passwords, credit card details, or other sensitive data. The data capture is performed, for example, using a classic man-in-the-middle attack (someone who can see the traffic passed between the client and server, or even the provider). The attacker then attacks the web server by deploying the new, modified Bleichenbacher attack to get hold of the pre-master secret key. If successful, all of the TLS data that has been captured can be decrypted with this key. And it doesn’t matter when the traffic was captured – for example, TLS traffic captured in the past can still be decrypted, posing a considerable hazard in the case of data-hungry services.

I’m a Managed Server customer with Is there anything I can do?

No. Our engineers are constantly following developments like these, planning ahead, and quickly taking countermeasures. Sometimes these measures are publicly noticeable because the service (e.g. vulnerability to protocols/services such as SSH, Postfix, etc.) or the server (e.g. kernel vulnerability) have to be restarted [2]. Other times, it simply requires deploying a package – which goes practically unnoticed by you. In case you’ve wondered what all of these security upgrades showing up in the activity feed are, they are simply there to show you that our systems are constantly being updated. This is to minimise the likelihood of vulnerabilities in the systems at from being exploited. We should of course point out that this is always a cat-and-mouse game and that hackers are one step ahead. Still, we do everything in our power to make their lives as difficult as possible.

I’m a Root customer with Is there anything I can do?

Yes. As a server administrator with root access, you’re solely responsible for patching security gaps. We’ll explain what you need to keep in mind below.

How can I protect myself against DROWN?

If you are merely a client user, there’s nothing for you to do here except to always use a current browser. Unfortunately, this alone doesn’t solve the problem since the vulnerability ‘only’ affects the server. This is why (your) server administrators must take action.

The server vulnerability has two key characteristics:

  • SSLv2 connections allowed to the server
  • private keys shared with any server that supports SSLv2.

The second risk in particular is quickly underestimated or overlooked. For example, if your mail server supports SSLv2 and also protects your web server with the same SSL certificate, cracking the mail server also makes it possible to capture traffic from the web server (since the master RSA key is cracked at the same time here). It is therefore crucial that you also make sure all of your company’s servers deny SSLv2 connections or no longer support this protocol. First you should check whether your website and server still support this protocol. The team that discovered the gap provides a database [1] that you can use to check whether your server was vulnerable at the time of discovery. We should point out here that this is not a ‘live’ check (this is to prevent any layman from checking their status on the server, the operative word being ‘layman’. Potential attackers will of course find plenty of other avenues.).

Vulnerable services include:

  • Apache (no risk for versions 2.4 and upward, no official Apache developer statement currently available) [3]
  • Nginx (versions before 0.7.64, 0.8.18 and earlier support SSLv2 by default – these should be disabled, no official Nginx developer statement currently available, click link below for instructions on disabling) [4]
  • Postfix (from 2.9.14, no hazard with releases after 20 July 2015) [5]

Probably the most important step is to deactivate the SSLv2 protocol. As mentioned several times already, it is obsolete and no longer used, so it can be disabled without any problems. Due to various and complex server configurations, we cannot provide a single set of instructions for this procedure, but here are a few of the main points to keep in mind:

  • Make sure SSLv2 is disabled.
  • Use modern web servers and keep them up-to-date (for example, Apache does not support SSLv2 communications)
  • Update OpenSSL: the vulnerability can be exploited even more quickly with the previously mentioned bugs [6] (faster in terms of the time required to crack the master key). OpenSSL 1.0.2 should be updated to 1.0.2g; OpenSSL 1.01 to 1.0.1s. [7]

Taking these precautions is strongly recommended. For more information about DROWN, refer to the link list below or visit the official website of the DROWN discovery team [8].