RFC: Change the order of Nsock SSL connection attempts and fallbacks

[Daniel Miller <bonsaiviking () gmail com>]

Proposed: First attempt a modern SSLv3-and-higher handshake before falling
back to SSLv2 instead of attempting an SSLv2-compatible handshake and
falling back to non-SSLv2 if that fails.

Currently, when a program (Nmap -sV, NSE, Ncat, etc) tries to connect via
SSL/TLS to a service, it follows this basic logic:

1. connect via TCP
2. Try connecting with the SSLv23_client_method.
3. If OpenSSL has been compiled with SSLv2 support, as we do for our binary
packages for Windows, OS X, and Linux (RPM), then this sends an
SSLv2-compatible handshake, which certain TLS-only servers will reject.
4. If the handshake was rejected, the TCP connection is closed. We add the
SSL_OP_NO_SSLv2 option to change the handshake type to a standard SSLv3-TLS
handshake and try again.

In today's networks, it seems to me like there would be more servers that
would reject an SSLv2-compatible handshake than would not accept the
non-SSLv2 version. I believe that if we change the order of connection
attempts (try non-SSLv2 first, then fall back to SSLv2 if that fails), then
we will avoid most of these reconnections since there are more TLS servers
than SSLv2-only.

Additional complications:

* NSE scripts that rely on the specialized setup functions (STARTTLS) in
sslcert.lua will fail if Nsock reaches the fallback condition, because the
application is not informed if the connection is reset and reopened during
a "reconnect SSL" attempt.
* Some servers are even rejecting SSLv3 handshakes, only accepting TLSv1
and higher.
* This fallback logic is followed regardless of whether the OpenSSL linked
is capable of performing SSLv2 connections. They recently disabled that by
default, and most Linux distros have followed suit. This means that we are
needlessly and fruitlessly reconnecting when we could just fail quickly.
* Nsock currently just exposes one setting regarding TLS/SSL options:
NSOCK_SSL_MAX_SPEED, which means "don't seed the RNG, try SSLv2-compatible
handshakes, and use ALL ciphers with some ordering to prefer 'fast'
ciphers". These assumptions should be revisited, as well as possibly
allowing applications to have more control over options.

Please chime in with your thoughts.

Dan

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/