3 ms·
So, disable SSLv2. That is not new information. I like how the FAQ insists you are still at risk if you've disabled SSLv2 because you still might be using it so
by skywhopper 11y ago
So, disable SSLv2. That is not new information. I like how the FAQ insists you are still at risk if you've disabled SSLv2 because you still might be using it somewhere else!!! In other words, if you've not disabled SSLv2 everywhere, then there are still places where SSLv2 is enabled. Thank you.
- Steuard 11y agoI expect you already understand this, but to be clear: the risk appears to be that even one forgotten old server (or service) running SSLv2 can put your up to date, highly secure servers at risk (if you've shared keys between them). To my eye, the way you've phrased it here could be read to imply "any server with SSLv2 disabled is safe". The linked report says this is incorrect, and its inaccuracy is responsible for roughly half of the vulnerabilities that they have observed.
- skykooler 11y agoSo, disable SSLv2 and get a new key, and only share it between servers with SSLv2 disabled.
- pfg 11y agoNote that the private key isn't actually leaked (as opposed to Heartbleed), so it wouldn't be necessary to revoke the old certificate and use a new key. Rather, DROWN uses an existing SSLv2 service with the same key as an Oracle to decrypt (usually secure) TLS connections. It's still a good idea to not share keys to limit the exposure for future attacks.
- deleted 11y ago[deleted]
- syncsynchalt 11y agoAlso, disabling SSLv2 in versions of openssl up til January did not actually disable SSLv2.
- pfg 11y agoOr, more specifically, disabling all SSLv2 ciphers didn't disable SSLv2 entirely. Disabling SSLv2 as a protocol worked.