5 ms·

Oh 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.

• PythonicAlpha 11y ago
  One reason: Using a distribution that uses old OpenSSL versions (see my own post).
• cjbprime 11y ago
  > 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."
  • pfg 11y ago
    I think it's a little bit more complicated than that, and depends on how SSLv2 was disabled. From the OpenSSL 1.0.2f release notes: SSLv2 doesn't block disabled ciphers A malicious client can negotiate SSLv2 ciphers that have been disabled on the server and complete SSLv2 handshakes even if all SSLv2 ciphers have been disabled, provided that the SSLv2 protocol was not also disabled via SSL_OP_NO_SSLv2. So if you disabled all SSLv2 ciphers, but didn't actually disable SSLv2 itself, you could still complete a SSLv2 handshake. If your server software disables SSLv2 via SSL_OP_NO_SSLv2, then you're fine. This seems to be the case for (at least) nginx, based on how I read the code.
• deleted 11y ago
  [deleted]