In vulnerability management there are few things worse than the false negative.  Analysts happily going about their day, thinking things are fine while skr1pt kiddies are doing somersaults  through old vulnerabilities.  In my case we were looking for systems that still supported SSLv2.

I was most recently caught by the false negative situation when asked to do a verification of some settings changes aimed at tightening up the crypto on some of our web servers.  It being a busy day I turned to the trusty nmap scanning tool to perform the verification that SSLv2 was, in fact, disabled on these web servers.

nmap --script ssl-enum-ciphers -p 443 [hostname]

nmap -sV -sC -p 443 [hostname]

I look through the results of both checks, no sslv2.  No complaints, no problem, right?  WRONG!

More secure is always better, right?  Well, not if you are responsible for vulnerability management.  In this case the default crypto libraries on Windows no longer support SSLv2 and therefore don’t detect it as an available option when offered by the server.  This results in certain tools returning the dreaded false negative.

Knowing there’s a problem is a big step towards the solution.  There are still specialized tools available that use various methods to detect supported ciphers and protocols that can help.

If you have a web facing system and want to do a quick check there is always Qualys SSL Labs.  I’d recommend selecting the ‘do not show the results on the boards’ tick box, at least time you run your site.

My favorite offline tool for this task is testssl.sh.  Unfortunately it is only Linux or Cygwin so you are out of luck native on Windows.  I haven’t tested this on the new bash shell for Windows.  Anyone tried it?  Send feedback with your results.

If you are testing from a Windows box ssl scan is always an option.

Hope this helps. Happy hunting!

You can find my post on securing TLS on your system here:  HTTPS check. Secure? Maybe.

Have feedback?  Feel free to leave it in the comments or find me on Twitter @JaredGroves