nsock_connect_ssl cannot connect to SSLv2 server

[dmiller-nmap]

Due to the use of SSL_set_tlsext_host_name in nsock/src/nsock_core.c, SSLv2 is precluded when scanning systems by name (as opposed to by IP address) because SSLv2 does not support extensions. SSLv3 also does not support extensions, but is allowed as a fallback. SSLv2 is never allowed as a fallback, so it has to be negotiated correctly from the beginning.

Low priority, probably, but we should make every effort to allow Nmap to connect to all SSL/TLS servers. Observations:

• Some packaged OpenSSL libs have SSLv2 neutered. Be sure to test with OpenSSL compiled from official upstream sources.
• We try to use SSLv23_client_method to allow this, but it's not working. We use "ALL" in our ciphers list, so SSLv2 should be ok.
• We already have a "try again" manual fallback setting SSL_OP_NO_SSLv2 for the case where SSLv23_client_method fails because the server doesn't accept SSLv2 handshakes. This currently isn't exercised in cases where there's a hostname available, because of the reason listed above.

[h4ck3rk3y]

Just wondering, was this issue discovered with the DROWN attack in mind?

[dmiller-nmap]

@h4ck3rk3y Was trying to determine if ssl-cert.nse could grab certs from SSLv2-only servers. That question is still open, because I ran into this bug instead. But yes, DROWN prompted the check.