Do Not Drown Your HTTPS Servers in the DROWN Attack

Wednesday, March 9, 2016

Newly discovered vulnerability in SSL 2.0 can be used to exploit latest TLS

drownWhat happens when you leave an unattended child at the deep end of a swimming pool? It puts the child at risk of drowning. Such analogy can be related to the HTTPS protocol (the child), when left unattended, is at risk of vulnerabilities because of its inability to adapt on its own. SSL Certificate has long been present in the cybersecurity industry for its use of encryption and authentication.

Fundamentally, most tech specialists know about SSL/TLS and installing the protocol in web servers is by mean not a difficult task at hand. However, what’s worrisome is how IT professionals tend to neglect the need to care for them.

What is DROWN Attack?

Just recently, researchers have found yet another vulnerability with an old protocol of SSL – SSL 2.0. This newly discovered vulnerability called DROWN (Decrypting RSA with Obselete and Weakened encryption) breaks the encryption between two communicating parties, thereby stealing personal information.

It is said that 22% of servers may be vulnerable to the DROWN attack because it supports the old SSL 2.0. It doesn’t matter if the protocol is not activated, as long as it is enabled, there is a risk of servers falling into the DROWN attack.

Are you Vulnerable to a DROWN Attack?

To check whether your websites are vulnerable, you can make use of the DigiCert® SSL Installation Diagnostics Tool. Alternatively, to check on vulnerabilities on all servers in the network, DigiCert® Certificate Inspector tool can easily help you with that by summarizing all vulnerabilities in a dashboard.

What to Do Next?

If your servers are found to be vulnerable to the DROWN attack, you should disable SSL 2.0 right away. Fixing it is easy.

  • OpenSSL: If you are using OpenSSL, the easiest solution is to upgrade to recently released versions of OpenSSL 1.0.2g and1.0.1s. You should also upgrade to these if you are still using one of the older (no longer supported) versions of OpenSSL.
  • Microsoft IIS: If you are using IIS 7 or newer, SSL v2 is disabled by default. If you manually enabled support for SSL v2, go back and disable it. If you are running older (no longer supported) version of IIS, then upgrade to IIS version 7 or newer.
  • Network Security Services (NSS): If you are using NSS 3.13 or newer, SSL v2 is disabled by default. If you manually enabled support for SSL v2, you need to go back and disable it. If you are using an older version of NSS, simply upgrade to NSS 3.13 or newer.
  • Apache, Nginx, etc.: If your servers support SSL v2, you need to disable support for it.

As a gentle reminder, don’t neglect SSL certificates after installing. Run a schedule check on all servers regularly to ensure that all known vulnerabilities are addressed by disabling weak ciphers suites and protocols.

Share :    

Back to Blog