The DROWN Attack
31–40 of 206 posts
Re: The DROWN Attack
#32From a pool of 11 million scans of HTTPS sites, I could only find ~265k targets with SSLv2 enabled [1]. That's 2.4%, not 25%. A breakdown of the type of target that have SSLv2 enabled would be useful to understand how they reached that number. It's possible that they scanned much much more than HTTPS on port 443, and found a lot of embedded devices with poor SSL configurations. At any rate, you should verify the conf…
> [edit 2] according to one of the researcher, the scanner "check if pubkey (not cert) runs on SSLv2. Then mark all others with that pubkey vuln" (src: https://twitter.com/seecurity/status/704665265712308224)
That seems to make sense, given that any SSLv2 service using a pubkey that's used on a non-SSLv2 service can be used in an attack against the latter.
The main takeaway from this is probably that it's a good idea to separate your SSL keys by service (or, more specifically, by DISTINCT($attack_surface), where $attack_surface is your software stack, OpSec, etc.). This would limit the impact of a number of vulnerabilities (think: Heartbleed) and should generally become a best-practice.
Re: The DROWN Attack
#33According to the info page, SSLv2 can only be disabled on OpenSSL by having the right (newer) version of OpenSSL installed. I just checked Debian versions. Wheezy (oldstable): Much to old OpenSSL versions, according to the info site Jessy (stable): Still to old OpenSSL version. Stretch (testing): Still to old OpenSSL version. Sid (unstable): The same version of OpenSSL as Stretch -- Still to old. What to do?
Disable SSLv2 everywhere.
Re: The DROWN Attack
#34According to the info page, SSLv2 can only be disabled on OpenSSL by having the right (newer) version of OpenSSL installed. I just checked Debian versions. Wheezy (oldstable): Much to old OpenSSL versions, according to the info site Jessy (stable): Still to old OpenSSL version. Stretch (testing): Still to old OpenSSL version. Sid (unstable): The same version of OpenSSL as Stretch -- Still to old. What to do?
Disable SSLv2 everywhere.
To make it more clear:
According to the info page, I can disable SSLv2 on OpenSSL only by installing a newer version of OpenSSL, that is not available on Debian (as I found).
(I also updated my original post)
Re: The DROWN Attack
#35Re: The DROWN Attack
#36SSLLabs is the go to place for checks regarding your SSL/TLS setup.
https://www.ssllabs.com/ssltest/
DROWN is not yet marked there but you can look for "SSL 2" within the protocols section of the report.
Re: The DROWN Attack
#37Quote from paper: "Unfortunately, during our experiments
we discovered that OpenSSL servers do not respect the
cipher suites advertised in the
ServerHello
message.
That is, the client can select an
arbitrary
cipher suite in
the
ClientMasterKey
message and force the use of export cipher suites even if they are explicitly disabled in the
server configuration. The SSLv2 protocol itself was still
enabled by default in the OpenSSL standalone server for
the most recent OpenSSL versions prior to our disclosure."
Hopefully OpenSSL still honored a configuration setting to disable SSLv2?
Re: The DROWN Attack
#38Oh come on, it targets SSLv2. You better have a _damn_ good reason for still having SSLv2 enabled on your systems. If you didn't, you had this one coming.
> Oh come on, it targets SSLv2. You better have a _damn_ good reason for still having SSLv2 enabled on your systems.
"Unfortunately, during our experiments we discovered that OpenSSL servers do not respect the cipher suites advertised in the ServerHello message. That is, the client can select an arbitrary cipher suite in the ClientMasterKey message and force the use of ex- port cipher suites even if they are explicitly disabled in the server configuration. The SSLv2 protocol itself was still enabled by default in the OpenSSL standalone server for the most recent OpenSSL versions prior to our disclosure."
Re: The DROWN Attack
#39According to the info page, SSLv2 can only be disabled on OpenSSL by having the right (newer) version of OpenSSL installed. I just checked Debian versions. Wheezy (oldstable): Much to old OpenSSL versions, according to the info site Jessy (stable): Still to old OpenSSL version. Stretch (testing): Still to old OpenSSL version. Sid (unstable): The same version of OpenSSL as Stretch -- Still to old. What to do?
Jessie has 5 changesets on top of 1.0.1k which fix 14 CVE's:
http://anonscm.debian.org/viewvc/pkg-openssl/openssl/branche...
And similar for the other debian versions.
Re: The DROWN Attack
#40According to the info page, SSLv2 can only be disabled on OpenSSL by having the right (newer) version of OpenSSL installed. I just checked Debian versions. Wheezy (oldstable): Much to old OpenSSL versions, according to the info site Jessy (stable): Still to old OpenSSL version. Stretch (testing): Still to old OpenSSL version. Sid (unstable): The same version of OpenSSL as Stretch -- Still to old. What to do?
Typically, most server software has configuration options that allow you to specify which protocol versions are permitted (i.e. ssl_protocols in nginx, SSLProtocol in apache). Sometimes, they also bring defaults that are stricter than what OpenSSL supports by default.
The difference between older OpenSSL versions shipped by distributions and the latest version is not that newer protocols aren't supported, but that they haven't completely removed support for older, insecure protocols. For example, SSLv2 was only disabled by default in OpenSSL 1.0.2g, which was released today. Meanwhile, a lot of server software (e.g. nginx) had it disabled by default for quite some time now.
This is mostly relevant if you have code that uses OpenSSL directly - but then it's probably not a good idea to rely on OpenSSL defaults anyway.
tl;dr Older OpenSSL versions are probably fine as long as your server software has good defaults.