What is the Drown Attack?

The Decrypting RSA with Obsolete and Weakened eNcryption (DROWN) Attack is a serious vulnerability that affects HTTPS and other services that rely on Secure Sockets Layer (SSL)/Transport Layer Security (TLS).  

DROWN is an attack vector that leverages a cross-protocol bug in servers supporting modern TLS by using their support for the insecure SSLv2 protocol. SSLv2 is a 1990s-era predecessor to TLS and an obsolete version of SSL that has been deprecated for over a decade due to several security flaws.   

By using their support for the SSLv2, malicious actors can leverage an attack on connections using up-to-date protocols (i.e., TLS) that would otherwise be considered secure. 

DROWN only affects systems with weak encryption enabled and allows attackers to break the encryption used to protect your data. This allows them the ability to decrypt, read, and steal sensitive communications like passwords, credit card numbers, and more. In some situations, attackers may also be able to impersonate trusted websites and intercept or change the content a user sees.  

Is Your Server Vulnerable?  

Modern servers and clients use the TLS encryption protocol. However, if you have a website, mail server, and other TLS-dependent services, you may still be susceptible to this attack.  

Diving deeper, due to misconfiguration, many servers still support SSLv2. In practice, this support did not matter since no up-to-date clients actually use SSLv2 and supporting SSLv2 wasn’t considered to be a security risk as it wasn’t being used.  

However, DROWN shows that the act of merely supporting SSLv2 is a threat to modern servers and clients. It allows an attacker to decrypt modern TLS connections between up-to-date clients and servers by sending probes to a server that supports SSLv2 and uses the same private key.  

A server is vulnerable to DROWN if:  

  • It allows both TLS and SSLv2 connections. This is actually surprisingly common, due to misconfiguration and inappropriate default settings. 
  • Its private key is used on any other server that allows SSLv2 connections, even for another protocol. For instance, many companies reuse the same certificate and key on their web and email servers. In this case, if the email server supports SSLv2 and the web server does not, an attacker can take advantage of the email server to break TLS connections to the web server. 
  • It shares a public key with a server that allows SSLv2 connections. If one server allows TLS connections and one supports SSLv2, the SSLv2 server can be used to attack the TLS server.  

There is nothing practical that web browsers or other client software can do to prevent DROWN. Only server operators are able to take action to protect against the attack. 

You can only be sure that you are not vulnerable if none of your services sharing a given private key enable SSLv2. None of Globalscape's products support SSLv2 by default—but it is still available and can be enabled by the customer. 

How Can You Be Sure? 

To protect against DROWN, server operators need to ensure that their private keys are not used anywhere with server software that allows SSLv2 connections. This includes web servers, SMTP servers, IMAP and POP servers, and any other software that supports SSL/TLS.  

For security's sake, do an audit of all of your systems to ensure that none of your websites, mail servers, file servers, and so on have SSLv2 enabled. If you discover that you have servers or services that still support SSLv2, the fix is straightforward: disable SSL v2 immediately in all SSL/TLS servers. 

 According to the DROWN Attack website: 

"Merely allowing SSLv2, even if no legitimate clients ever use it … allows an attacker to decrypt modern TLS connections between up-to-date clients and servers by sending probes to any server that supports SSLv2 using the same private key…. Even if you’re certain that you have SSLv2 disabled on your HTTPS server, you may be reusing your private key on another server that does support SSLv2. We recommend manually inspecting all servers that use your private key." 

The website provides a tool in which you can check whether your private key is exposed elsewhere on the Internet. 

Additional Steps  

SSL was designed by Netscape in the 90s; the current version of the protocol is TLS 1.3. We strongly recommend upgrading OpenSSL to the latest version and eliminating all SSL support in favor of TLS. releases updates to their libraries as vulnerabilities are detected and repaired.  

Globalscape updates the libraries used in their products as new releases become available. For news about product updates, visit our Support page.