A very interesting script written by Bojan Zdrnja — the script itself can be found on GitHub. Note that I had to upgrade namap to nmap-6.25 with the command
brew install nmap
In last year or two, there has been a lot of talk regarding correct usage of SSL/TLS ciphers on web servers. Due to various incidents more or less known incidents, web sites today should use PFS (Perfect Forward Secrecy), a mechanism that is used when an SSL/TLS connection is established and symmetric keys exchanged. PFS ensures that, in case an attacker obtains the server’s private key, he cannot decrypt previous SSL/TLS connections to that server. If PFS is not used (if RSA is used to exchange symmetric keys), then the attacker can easily decrypt *all* previous SSL/TLS connections. That’s bad.
However, the whole process of choosing a cipher is not all that trivial. By default, the client will present its preferred cipher to use and as long as the server supports that cipher it will be selected. This is, obviously, not optimal in environments where we want to be sure that the most secure cipher will always be selected, so administrators quite often enable their servers so they get to pick the preferred cipher.
This allows an administrator to enable only ciphers he wants to have used, and additionally to define their priorities – the server will always try to pick the cipher with the highest priority (which should be “the most secure one”). Only if the client does not support that cipher, the server will move to the next one and so on, until it finds one that is supported by the client (or, if it doesn’t, the SSL/TLS connection will fail!).
This is good and therefore I started recommending web server administrators to configure their servers so that PFS ciphers are turned on. However, at several occasions I noticed that the administrators incorrectly set the preferred cipher suite order on the server. This can result in non-PFS cipher suites selected, although both the server and the client support PFS.