We use own and third party cookies to improve our services, by analyzing your browsing habits. If you go on browsing, we will consider you are accepting its use. You can change the settings or get more information on our cookies policy Cookie policy


Drown vulnerability, a new SSL threat

This new vulnerability is not as critical as the known heartbleed but updating the SSL systems is necessary to maintain secure connections.

Author photo Fernando Ortega @Fernando,

Drown, the new vulnerability for SSL connections

Drown (decrypting RSA With Obsolete and Weakened encryption) is a new threat for SSL connections that affects millions of sites with HTTPS and against which the best prevention is updating systems and the application of security patches to prevent security gaps.

An attacker can exploit this vulnerability to use the SSLv2 protocol to decrypt connections under TLS. Currently the SSLv2 protocol is disabled in virtually all SSL servers because it is considered unsafe and totally obsolete. This attack allows you to use that protocol against servers that only accept TLS.

In practice, it is not so easy for an attacker to get succeed in an attack as it would in previous vulnerabilities as heartbleed, but in any case poses a risk, so the recommendation is that all system administrators update their servers with security patches and also with recently released updates for the most popular operating systems, or performing manual updates for OpenSSL.

The vulnerability does not compromise the private key of server. Only it affects individual sessions and could commit only to those sessions. So, no need to regenerate the SSL server key.

Is my server vulnerable to DROWN?

Short answer: It depends on the server configuration.
Long answer: You can only be sure that it is not vulnerable or because you update and applied security patches, or because none of server services that share a private key has enabled SSLv2 protocol. For example, an Apache server is vulnerable if it shares the private key with an email server that does have enabled SSLv2.

Recommended settings

As a first action, you should upgrade both OpenSSL and the server services to the latest version available. In addition, it is recommended to consider the following guidelines:


SSLProtocol All -SSLv2 -SSLv3


ssl_protocols TLSv1 TLSv1.1 TLSv1.2


# Minimal recommended settings. Whenever the built-in defaults are
# sufficient, let the built-in defaults stand by deleting any explicit
# overrides. The default mandatory TLS protocols have never included
# SSLv2, check to make sure you have not inadvertently enabled it.
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
tlsproxy_tls_protocols = $smtpd_tls_protocols
tlsproxy_tls_mandatory_protocols = $smtpd_tls_mandatory_protocols

smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
lmtp_tls_protocols = !SSLv2, !SSLv3
lmtp_tls_mandatory_protocols = !SSLv2, !SSLv3

smtpd_tls_ciphers = medium
smtp_tls_ciphers = medium

# Other best practices

# Strongly recommended:
# http://www.postfix.org/FORWARD_SECRECY_README.html#server_fs
smtpd_tls_eecdh_grade = strong

# Suggested, not strictly needed:
smtpd_tls_exclude_ciphers =
smtp_tls_exclude_ciphers =

Related links:

More information about this vulnerability

Security advisory released by OpenSSL


    Click para elegir imagen