Audit or review Ncat's use of SSL/TLS

[bonsaiviking]

Nmap tends to view SSL/TLS as just another communication protocol to be negotiated, so we don't do certificate verification or try to prevent downgrades: we just want to be able to talk to the maximum number of services possible.

Ncat is different: SSL is offered as a security feature. We need to make sure we are making wise decisions here. We are way behind the curve in comparison to web browsers, in terms certificate verification, OCSP stapling, certificate pinning, revocation checking, etc. We have a decent set of supported ciphers (and now allow users to override it), but we also support SSLv3 and don't offer a way to change that.

This task is to perform at least an initial assessment of how Ncat meets or falls short of what is expected of an SSL client (and server, really, because we offer that, too). Assumption can be made that we are working with the latest version of OpenSSL, because that is what we use in our binary packages (Windows and Linux RPM. Not sure of OS X .dmg?)

[fyodor]

Nice. It's worth noting, I think, that Ncat is a lot different than a web browser in terms of security expectations. In particular:

• Ncat is more commonly used for debugging networking/security issues and so connecting to an "insecure" server is commonly desired. So in general we should provides warning more than strict enforcement. Or when we're strict, we should at least mention the command-line option to be more lax.
• Ncat has far more sophisticated users, so some of things web browsers do to force/encourage "more secure" actions on their users might feel condescending to Ncat users.
• Ncat as a server generates a self-signed certificate by default and it is pretty common that a user would then connect to it with an Ncat client. Hopefully they check the fingerprint of the generated cert if security is important but, in any case, we don't want to make this common use case more difficult than it has to be.

I still think this assessment is important, just noting that we don't need to necessarily be as strict as web browsers in enforcing SSL/TLS best practices.