4 ms·
From 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
by jvehent 11y ago
From 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 configuration of your websites. There are many tools to do that, and we publish configuration sample to make it easy: https://mozilla.github.io/server-side-tls/ssl-config-generator/ https://mozilla.github.io/server-side-tls/ssl-config-generat...
[1] https://twitter.com/jvehent/status/704657734810148864 https://twitter.com/jvehent/status/704657734810148864
[edit] the page https://drownattack.com/top-sites https://drownattack.com/top-sites shows that sites like yahoo.com are vulnerable, but there are no details as to why it is listed vulnerable. yahoo.com does not allows connections with SSLv2, but some of its subdomains do, so maybe the top-level domain is listed because some of its subdomains are vulnerable?
[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 https://twitter.com/seecurity/status/704665265712308224)
- deleted 11y ago[deleted]
- pfg 11y ago> [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 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.
- dadrian 11y agoDue to CVE-2015-3197, many servers using OpenSSL reported they supported no SSLv2 ciphers, which causes OpenSSL-based SSLv2 clients to hang up. However, if you aggressively choose a cipher and continue the handshake, the server will still negotiate the connection. As a result, most existing scanning tools vastly underestimate SSLv2 support.
- yeukhon 11y agoWait, what? Is there a PoC script?
- tptacek 11y agoIt's not enough to not run SSLv2 on the target; SSLv2 can't be available on any server that shares the same RSA keypair. It's a cross protocol attack, where attackers use the SSLv2 server as a tool to attack the TLS server.