The POODLE vulnerability exploited a weakness in SSLv3. The newer DROWN vulnerability exploits a weakness in SSLv2. Part of my protection against POODLE (for my webserver) was to disable SSLv3 and earlier.

So am I already safe from DROWN?


4 Answers 4


Be aware that a recent OpenSSL version had a bug (CVE-2015-3197) that allowed a client to negotiate disabled cipher suites (such as SSLv2's EXPORT ciphers, for DROWN) even if they were disabled in OpenSSL at runtime. Make sure you're up to date (always a good idea anyhow, of course, especially with stuff like OpenSSL), and disable all versions of SSL. Don't forget to restart your server processes after updating the library, so it picks up the new version of the OpenSSL library.

Also, be aware that DROWN can be exploited across servers hosting different protocols (for example, using an email server to attack an HTTPS connection) if the other server supports SSL2 and is using the same public key as your web server. Since re-using public keys is reasonably common, and since secure connections to email servers (and similar) are usually not subject to as much scrutiny as web server connection security, you might still be vulnerable to DROWN even if your web server doesn't allow SSLv2.


POODLE is an abuse of a flaw in SSL 3.0. You are technically protected against POODLE if you disabled support for SSL 3.0.

DROWN leverages a flaw in SSL 2.0. You might be technically protected against POODLE, in the sense explained above, and still be vulnerable to DROWN.

Of course, SSL 2.0 has other flaws and it was already deprecated / forbidden; it has been so for a long time. The advice for POODLE was often worded as "deactivate everything that is older than TLS 1.0" and this includes SSL 2.0, but, honestly, SSL 2.0 should have already been deactivated, killed, and its corpse dumped at sea, long before POODLE. If you had to wait for POODLE to disable SSL 2.0, then you were already very very sloppy. There is no upper limit to sloppiness, so you are encouraged to test whether your server still accepts SSL 2.0. Just in case.

  • 65
    "There is no upper limit to sloppiness". I want that on a shirt with a graph showing a half-parabola going up...
    – Joe
    Mar 2, 2016 at 20:36
  • This is mostly correct, but the POODLE attack is also possible through TLS 1.2.
    – Parker
    Mar 4, 2016 at 15:14
  • 2
    @vallismortis: POODLE works against implementations that do not validate CBC padding contents. This is a protocol flaw in SSL 3.0 because in SSL 3.0 padding contents cannot be validated. This is an implementation flaw in TLS 1.0+ because some implementations did not do things properly. If POODLE is applicable to your TLS 1.0+ server, then you are using buggy, vulnerable software that you should have patched a year ago, and you have bigger problems, namely that you do not apply security fixes with the required promptness. Mar 4, 2016 at 15:17
  • "There is no upper limit to sloppiness" is a not an answer. How precisely does knowing there is "no upper limit to sloppiness" answer my question "am I already safe from DROWN". And my question is for the case that SSLv2 was already deactivated.
    – Raedwald
    Mar 4, 2016 at 15:30
  • @Raedwald I agree. This is an incomplete answer that disregards information you provided in the question and essentially restates the question in the form of an answer. I'm uncertain how it received so many upvotes.
    – Parker
    Mar 4, 2016 at 15:32

It depends.

You're vulnerable to DROWN if ANY server has the same RSA key as yours and is running SSLV2 and allows the low security "export cipher". Examples of this might be a certificate with multiple alternative names, or a wildcard certificate.

For example:

You disabled SSLV2 and SSLV3 on your webserver. Another admin in your organization, Bob shares the same SSL certificate with you, with both being signed with an alternative name, and thus share the same RSA key. Your server is www.mydomain.com running https, and Bob's server is email.mydomain.com, running SSL over SMTP.

Bob is a bit more sloppy about SSL, and didn't disable SSLV2 on his server. Since you both have the same RSA key, an attacker can use Bob's badly configured server to compromise the SSL security of your properly configured server.

  • 3
    @Mindwin There's other legitimate concerns than simply security. Configuration management is a big deal. If you had a cloud of 1000 servers would you really want to get 1000 certificates for them? Organizations are complex and have different needs and concerns. I think the important part is understanding the tradeoffs involved, which isn't always obvious. Sharing certificates isn't a great idea for security, but it might be the best you can do when considering everything else. Mar 3, 2016 at 15:53
  • In addition to running SSLv2, the attacker must be able to specify an export cipher.
    – Xander
    Mar 4, 2016 at 15:30
  • @Xander You're right. I neglected that part. Making an edit. Mar 4, 2016 at 18:02

SSL Labs currently has a test for the DROWN attack on their staging server, and they have an excellent write-up on the vulnerability.

Some of the more salient points that may have already been touched on in other answers:

...we have known SSL v2 to be insecure for a very long time—over 20 years.

...DROWN actually makes things worse, because it abuses SSL v2 to attack all other protocols

...the security of a server can’t be determined only by looking at its configuration. For DROWN, we have to look for the presence of the server’s RSA keys and/or certificate hostnames elsewhere.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .