Comments on the DROWN Vulnerability


I manage some sites that use Transport Layer Security(TLS). That is, they serve pages using URLs that begin with “https.” I was interested, therefore, in the discovery of yet another implementation bug in SSL/TLS implementations. This is the DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) vulnerability. At the end of this post are links to very readable descriptions of the vulnerability, why it matters and what one can do (and should already have done) about it.

Before we get to the link, though, I’d like to discuss an important issue: sometimes upgrading software is essential for security.

I am a firm believer in “if it ain’t broke, don’t fix it.” I guess it comes from having been a technician before being a software developer. My love for tinkering has given way to my desire not to have to fix things in a short time frame. Most software developers I know have the same mindset. But the corollary of that injunction is “if it’s broke, fix it” – and that is the case here. SSLv2 (the one that is the issue in DROWN) was fully deprecated in 2011. Nobody should use it. It seems, though, that millions of sites do use it, or, at least, they have it enabled for the web or email so it could be used. That’s the issue.

Now, I understand the need to support old client software. In this case, I know there are clients in use that haven’t been updated in a decade and don’t support modern protocols such as TLS 1.2. But it’s time, folks! I get it; I really do. I know it costs money to update and test and deploy software, and to train users in its use. But sometimes you have to do it to keep from losing any semblance of security you have left.

The issue here is that clients can tell a server to use old 40-bit encryption. Today the recommendation is 256-bit! As we discuss in Learning Tree’s System and Network Security Introduction, people can use the processors in video cards (or many virtual video cards on Amazon) to break older encryption in a reasonable time these days. In this case, breaking the encryption can lead to the discovery of the site’s secret key for site security!

If you are interested in the technical details of the attack, two useful resources are: and an article in ArsTechnica. Check the sites you manage or use for SSLv2. Fix the ones you own or manage and be wary or the others. While there aren’t any exploits for this vulnerability in the wild (yet!), it’s time to disable SSLv2 (and v3 while you’re at it). All sites should use – and clients should support – TLSv1.2 instead of the older SSL.


To your safe computing,
John McDermott

Type to search

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.