DROWN, a New Attack on OpenSSL: Millions of OpenSSL-Secured Websites Are at Risk!

A recently discovered security vulnerability in OpenSSL allows a long-deprecated protocol, SSL v2 (Secure Sockets Layer) to be misused in attacks at modern websites. The new attack has been, perhaps fittingly, dubbed DROWN, an acronym for Decrypting RSA with Obsolete and Weakened eNcryption. Cyber security analysts believe it might shut down–or shall we say drown, more than one third of all HTTPS servers. Is yours one of them?

Your server is vulnerable to DROWN if:

• it allows SSLv2, OR(!)
• it uses a private key that is also in use by any other server software that allows SSLv2 connections (such as your mail server!).

Upgrade your OpenSSL software asap. OpenSSL 1.0.2 must be upgraded to version 1.0.2g. OpenSSL 1.0.1 must be upgraded to version 1.0.1s. Should you be using an older version, now is the time to upgrade to 1.0.2g or 1.0.1s.

Having said that, an OpenSSL update won’t do you any good unless your SSL configuration is up close to flawless. You must deactivate SSL protocols (regardless of the version) as well as TLS 1.0. Your server should only support TLS versions 1.1 and 1.2.

DROWN shows that merely supporting SSLv2 presents a threat as it allows an attacker to probe and then decrypt connections between up-to-date clients and a server.

For an explanation on how you can verify your configuration, check out this short CloudInsidr Tip of The Day: Test Your Web Server’s Crypto Prowess for TLS, Diffie-Hellman, and more. For more on how to configure HTTP/2 with TLS Encryption in NGINX, read this post.

Given all recent cyber security vulnerabilities it seems that not enough is being done to prevent future attacks. Most websites of industry heavyweights like Apple, Dell, EMC, Microsoft, RSA, and others have neither CSPs (Content Security Policies) nor even a protection against XSS (Cross Site Request Forgery) attacks in place. Don’t let that be your web server.

Check out these CloudInsidr articles:

• Secure Your Web Server against Attacks via XSRF/CSRF/XFS: How to Design a Content Security Policy
• Fixing your Web Server’s Security Headers: From Hall of Shame to Hall of Fame