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?
Asked
Active
Viewed 5,792 times
4 Answers
63
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.
Thomas Pornin
- 326,555
- 60
- 792
- 962
-
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 02 '16 at 20:36
-
This is mostly correct, but the POODLE attack is also possible through TLS 1.2. – Parker Mar 04 '16 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. – Thomas Pornin Mar 04 '16 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 04 '16 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 04 '16 at 15:32
-
@vallismortis as for upvotes, I guess it's because it actually points out, that the question shouldn't have been asked in the first place. If someone asks whether disabling SSLv2 two years ago protects him, it actually shows he/she is only being reactive. Which, when it comes to security, is by definition not enough. So you are right, it doesn't answer the question, but conveys that the there is a more substantial problem elsewhere. While it is not a very encouraging for someone who might have been thinking he's been doing the best he could, it should be eye-opening. – peterph Mar 05 '16 at 18:07
36
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.
Steve Sether
- 21,620
- 8
- 51
- 78
-
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. – Steve Sether Mar 03 '16 at 15:53
-
In addition to running SSLv2, the attacker must be able to specify an export cipher. – Xander Mar 04 '16 at 15:30
-
23
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.
CBHacking
- 48,401
- 3
- 90
- 130
0
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.
