A recently discovered vulnerability with SSLv2, dubbed the “DROWN” attack, has put the final nail in the SSLv2 coffin. Despite SSLv2 being deprecated since 2011, a large number of web servers, email servers, and other SSL-enabled servers still provide support for the outdated protocol. In fact, more than 33% of all Internet-accessible sites have been shown to support SSLv2—making this a viable attack scenario.
Merely supporting SSLv2 on any server allows an attacker to conduct the attack, even though no modern clients support SSLv2. If the attack is successful, an attacker could decrypt network connections between clients and servers, as well as perform a man-in-the-middle attack.
This attack is a cross-protocol Bleichenbacher padding oracle attack, in which the attacker is able to derive the RSA session keys of an encrypted connection and then use that key to decrypt a connection. One aspect that makes this attack interesting is that web servers are not the only server types vulnerable. Any protocol that supports SSLv2 is susceptible—meaning mail servers that support POP, IMAP, or SMTP with SSLv2 are also vulnerable.
Further, it is possible for an attacker to conduct the attack across servers that share private keys. Therefore, if your mail server and your web server share the same private key, and one of them supports SSLv2, both servers may be vulnerable to the attack. Although a rarity, this is still an interesting possibility.
If you have not disabled SSLv2 on your network or in your applications, now is the time to do so. Many modern web and email servers have SSLv2 disabled by default, but many legacy servers have not. For example, Microsoft IIS versions 7.0 and above, as well as many cryptographic libraries built into server software, should have it disabled by default. However, current versions of OpenSSL have SSLv2 enabled by default.
The OpenSSL team has released an update to fix this behavior, as well as to address a number of other vulnerabilities that contributed to facilitating the DROWN attack. To mitigate this vulnerability, OpenSSL 1.0.2 users should upgrade to 1.0.2g and OpenSSL 1.0.1 users should upgrade to 1.0.1s, as both upgrades now disable SSLv2 during default builds. If you have servers or software under your control with SSLv2 enabled, your private keys should be okay and may not need to be changed, as this attack is only derives session keys. If you create a server product that includes OpenSSL or another cryptographic library, you should ensure that you are shipping in a “secure-by-default” configuration and disable SSLv2.
Readers interested in further details about this topic can reach us at: firstname.lastname@example.org