Verifying preferred SSL/TLS ciphers with 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.
As mentioned previously, this happens because the client sends the list of the supported ciphers and the server picks "the strongest one" according to its preferred list.
SSL Labs' (https://www.ssllabs.com/ssltest) shows this when testing with reference browsers, but I wanted to be able to check this myself, from command line, especially when I'm testing servers that are not reachable to SSL Labs (or I don't want them to see the results).
So I modified the Nmap's ssl-enum-ciphers.nse script to list preferred ciphers in addition to just enumerating ciphers. I use this script a lot to list the supported ciphers, but I was missing the preferred ciphers list. Let??s take a look at the following example:
$ nmap -sT -PN -p 443 127.0.0.1 --script ssl-enum-ciphers.nse
Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-11 09:15 UTC
Nmap scan report for 127.0.0.1
Host is up (0.00021s latency).
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| SSLv3: No supported ciphers found
| TLSv1.0:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| preferred ciphers order:
| TLS_RSA_WITH_AES_128_CBC_SHA
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA
| TLS_RSA_WITH_AES_256_CBC_SHA
| TLS_RSA_WITH_3DES_EDE_CBC_SHA
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
| compressors:
| NULL
Now, things get interesting. You can see that the server supports the PFS ciphers (those starting with TLS_DHE are the PFS ciphers) in the original list ( in green). However, take a look at the preferred cipher list (in red). Since the TLS_RSA_WITH_AES_128_CBC_SHA is the preferred cipher by the server, absolutely every browser today (Mozilla, Chrome, IE, Safari) will end up using this cipher ?? since they all support it. So, even though PFS ciphers are enabled, they will never get used!
Of course, this is an error in the web server??s configuration. Let??s fix it so the PFS ciphers have higher priority and rerun the nmap script:
$ nmap -sT -PN -p 443 127.0.0.1 --script ssl-enum-ciphers.nse
Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-11 09:15 UTC
Nmap scan report for 127.0.0.1
Host is up (0.00021s latency).
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| SSLv3: No supported ciphers found
| TLSv1.0:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| preferred ciphers order:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA
| TLS_RSA_WITH_AES_128_CBC_SHA
| TLS_RSA_WITH_AES_256_CBC_SHA
| TLS_RSA_WITH_3DES_EDE_CBC_SHA
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
| compressors:
| NULL
Much better! Now the PFS ciphers are preferred and most browser will use them. We can even confirm this with SSL Labs ?? all relatively new browsers, that support PFS will pick those ciphers.
So, if you want to use this script to test your servers, you can find it at https://github.com/bojanisc/nmap-scripts - please report any bugs to me.
Finally, I also submitted it to Nmap so hopefully it will get added into the official distribution. There is a bug that Daniel Miller noticed ?? in case a server supports more than 64 ciphers, and the server is running on Microsoft Windows, the script will fail to list the preferred ciphers.
The reason for this is that, when a client connects, Microsoft (the Schannel component I presume) takes into account only the first 64 ciphers listed by the client. The other ciphers are ignored. This is the reason why the original ssl-enum-ciphers.nse Nmap script splits ciphers into chunks of 64. No idea why Microsoft did it this was (since the spec says that the client can include as many as it wants). However, it??s clearly a problem.
Now, I haven??t seen any web servers that support more than 64 ciphers in the wild ?? let me know if you find one. Additionally, according to this article: http://msdn.microsoft.com/en-us/library/windows/desktop/bb870930%28v=vs.85%29.aspx, the list of cipher suites on Windows is limited to 1023 characters.
Since most cipher names are 20+ characters, this could mean that you can't really have more than ~50 ciphers active on a Windows machine - I haven't tested this though.
--
Bojan
bojanz@twitter
INFIGO IS
| Web App Penetration Testing and Ethical Hacking | Amsterdam | Mar 31st - Apr 5th 2025 |
Comments
A disclaimer needs added in ALL CAPS to that all-too-common statement above. PFS is all the rage from "security experts" and while it fixes one problem, enabling it could get your company hacked. PFS and cipher selection are not something that should be left to a general systems administrator who too often also runs the Internet systems. They might read what you and others have written, take your advice, and wind up with a massive breach.
How, you ask?
PFS completely and absolutely breaks any security system that relies on sniffing or bridge mode. All of your security devices like Snort, IDS, IPS, SPAN ports, Web App Firewalls, "NextGen Firewalls" and the like that work inline or use sniffing mode suddenly go completely blind and quiet.
If you're paying close enough attention and if your security devices have the correct capability, they will throw a log entry about an unknown cipher or something similar. But not all do that and I've never seen one where it was a major alert. In addition, many WAFs support a limited selection of ciphers. Enabling the wrong cipher, even a non-PFS one, can also cause your WAF or security device to be silently bypassed. There's a method of performing web app pentesting where you check for PFS ciphers, set your tools to use just those ciphers, and see if you can slip bad traffic through the WAF. If you can, you know some well-meaning admin screwed up in a major way. Or more likely, did an install with the defaults enabled.
The risk occurs because PFS does NOTHING to protect the security of the "data at rest" that a company holds about its customers, the bulk data. That's where all of the value and all of the risk to a company comes from. All it takes is one application-level vulnerability that the WAF or IPS was (formerly) protecting and your data is gone.
The ONLY thing PFS does is protect the security of individual "data in motion" transactions. Frankly, a company doesn't give a rat's patootie if a couple of customers get their transactions sniffed and decrypted later on as long as the majority of the data they hold remains secure. They don't make the headlines for one-off's. There is almost no way anyone could "reasonably assume" that a key was stolen AND used maliciously. That's the determination a company has to reach to make a breach reportable in almost all cases.
The only companies that have gotten tagged for data-in-motion breaches are those that allowed sniffers to get on their equipment, which PFS cannot fix, or that pulled a stupid stunt like not checking certificate validity or even passing traffic in clear text. Even the ones that got their private keys stolen and used to sign malware have gotten off easily.
Anonymous
Aug 11th 2014
1 decade ago
In this particular case, in order to use all those IDS and IPS devices, NG firewalls and so on, even with SSL/TLS that uses RSA for symmetric key exchange, you have to actually provide your server's private key to the IDS/IPS device. That also increases the risk a bit (all your private keys are now stored at a single device!).
Depending on the environment, you can always inspect the traffic "behind" load balancers/SSL terminators and similar devices, where it might be passed in clear text, so you can still have PFS at the front.
And of course PFS doesn't protect the security of "data at rest". That is why it's part of "TLS - Transport Layer Security" :)
But this is a valid point for sure, thanks for the comment.
Anonymous
Aug 11th 2014
1 decade ago
Possibly of interest to readers is:
https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_%28OTG-CRYPST-001%29
It is still in review phase, but therefore quite current. It mentions various tools, including nmap, to check for supported ciphers, misconfigurations and known vulnerabilities. Last night I experimented a bit with SSLScan and sslyze.
Note that OpenSSL < v1.0.0 does not support Elliptic Curves. Consequently you will not see any ECDHE ciphers from servers that support them. For example, the latest SSLScan_Win from https://code.google.com/p/sslscan-win/downloads/list comes with OpenSSL v0.9.8m.
sslyze (https://github.com/iSECPartners/sslyze , requires Python 2.7.x) did a good job (see the OWASP page for sample output). Using the "--regular" option it also lists TLS 1.1 and 1.2 cipher suites; I'm not sure whether nmap supports those.
Anonymous wrote:
> PFS completely and absolutely breaks any security
> system that relies on sniffing or bridge mode. All
> of your security devices like Snort, IDS, IPS, SPAN
> ports, Web App Firewalls, "NextGen Firewalls" and
> the like that work inline or use sniffing mode
> suddenly go completely blind and quiet.
Are you sure about this? Don't you mean "_SSL/TLS_ completely and absolutely breaks any security system that relies on sniffing or bridge mode"?
I am aware of "SSL sniffing" devices that conduct MitM attacks. Such devices create signed certificates on the fly (as a CA) and, from the client's point of view, act as the intended server. To prevent certificate errors, clients have to add the inspection device root certificate in their OS and/or web browser. The inspection device initiates an unrelated SSL connection to the intended server. AFAIK, whether or not PFS is used in any of both connections, is irrelevant.
Can you elaborate on specific cases/devices/applications where using PFS would imply that traffic _cannot_ be monitored, while you _could_ with SSL/TLS using RSA?
Anonymous
Aug 12th 2014
1 decade ago
This was Bojan's statement about the risk of installing the SSL certificate on the security device (it's another point of potential certificate compromise). But if you're not protecting physical and logical access to your security devices, you have bigger problems than the NSA.
With non-PFS sniffing (SPAN port) IDS or IPS or high-quality inline bridge WAF devices, you can install the web server SSL certificate on the security device. As the traffic passes by or through the device, it decrypts it on the fly. It's kind of the same thing as a static password being used for all traffic. Once you know that one password, you can intercept traffic, store it if desired and decrypt everything forever. With PFS, the security device goes blind on the first key rotation because the security device does not participate in the dynamic key rotation process; only the server and the client participate.
(Snort was a bad example because Sourcefire has said that Snort will never have SSL decryption capabilities built in. Even the Sourcefire commercial products rely on a third-party extra-cost box to decrypt the traffic and send it off to their appliances. Neither does FireEye. They, too, require a third-party decryption system. But you won't see that in either company's sales brochures anywhere. With "encrypt everything" being the mantra of the day, this has real security architecture design implications because encryption hides the bad traffic as well as the good data.)
I know that for VPNs you set the re-keying interval but I do not know how often the re-keying interval is for SSL/TLS web or email server PFS. I've never seen it specified anywhere so if someone knows or could point to the docs I'd appreciate it. And when does the first keypair change takes place? Is it immediately or after one hour or what? The implication of a delayed first rotation is that the first hour (or whatever) traffic might still be able to be decrypted by the initial public/private keypair. Since consumer HTTPS transactions are typically short-duration, if PFS rotation does not take place immediately, it's pretty much just hype.
Anonymous
Aug 12th 2014
1 decade ago
Anonymous wrote:
> PFS starts the initial connection in the same way but PFS
> dynamically changes the keypair at periodic intervals
I am not a cryptographer, but what I understand from the Diffie-Hellman key "exchange" (actually key _agreement_, no secrets are exchanged) is that the server's private key, associated with the public key embedded in the server certificate, is only used for authentication.
Hence, even if an attacker (or security MitM device) possesses the private key, it should not be possible to obtain any plaintext, neither from the initial connection, nor from "connections" after rekeying.
In addition to what Bojan wrote, quoting Ivan Ristic from
https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy
> Many network security devices, for example, can be
> configured to decrypt communication (and inspect traffic)
> when given servers' private keys. Without this capability,
> passive IDS/IPS and WAF devices have no visibility into
> the traffic and thus provide no protection.
If I understand correctly, this is exactly what you're trying to warn for. In that case this issue does not affect egress traffic from clients in your organization to external systems (of which you do not own private keys).
The issue may exist for those servers you manage, only in case you have placed copies of their private keys on security inspection devices, and only if you reconfigure those servers to support PFS (so don't do that, and watch out for server updates that add PFS support as an improvement).
In such cases, personally I would prefer to terminate SSL/TLS connections _before_ IDS and/or WAF devices, but perhaps conditions exist where such (proxy-like) solutions are undesirable or not possible.
Anonymous
Aug 12th 2014
1 decade ago
This is quite similar to the proverbial "Kids, don't try this at home" in the sense that an IT Admin should know better than to just turn something on because he read it on the Internet (be it SANS or anywhere else)
I find cryptography remains a dual-edged tool, with a complexity that is often overlooked by IT folks, and is completely oblivious to business people and the general public. Do it right and you're good and you know it, do it wrong and you think you're good and don't know it...
Being a one-man security show with limited resources and time, I tend to thread very carefully with cryptography. I am due to read (again) Applied Cryptography... Maybe one day it will all sink in...
PS. I, too, would favor disjointing TLS from the web server, enabling inline content analysis for IPS/IDS. But not so sure it ends there...
PPS. Do the words Risk Management and risk-based security mean anything anymore, to anyone ?
Anonymous
Aug 12th 2014
1 decade ago
Anonymous
Aug 13th 2014
1 decade ago
> PPS. Do the words Risk Management and risk-based security
> mean anything anymore, to anyone ?
Definitely.
The risk is that third parties obtain access to confidential information, transferred between two parties using SSL/TLS.
The impact depends on the application (type of information) and all possibly involved third parties.
The chances of this scenario taking place (threats) have increased over the past few years for multiple reasons, including:
1) We now have evidence of mass-surveillance by secret services and governments, often delegated to ISP's. Lots of people are involved and not only Snowden proves that not all people keep secrets. Anyone with access to equipment that processes or transfers confidential information may attempt to exploit it "for fun and profit". This threat has existed for quite some time but was probably underestimated in the past due to lack of awareness.
2) The Lavabit case has shown that a site owner can be forced to reveal the server's private key while not being permitted to inform his users (see http://www.theregister.co.uk/2014/08/11/spy_busting_dark_mail_relaunched_as_dime/ and http://www.theregister.co.uk/2013/10/03/lavabit_snowden_investigation_details/). Without PFS, anyone in possession of a private key can decrypt all recorded historic communication.
3) The use of mobile devices and apps that exchange confidential information has increased enormously. Also, the number and use of open WiFi networks has exploded, and thus the number of people that have access to related equipment (think hotels and restaurants). Also, "Evil Twin" attacks are well described and neither require sophisticated/expensive equipment nor extensive knowledge. A wireless MitM drone could be flying above you right now (see https://sensepost.com/blog/10754.html). Not only WiFi communications are vulnerable, see http://seclists.org/fulldisclosure/2014/Aug/14 and https://www.blackhat.com/us-14/briefings.html#Solnik
4) Recently backdoors were found in many SOHO modem/router brands that allow cybercriminals to (selectively) redirect traffic through proxies they own.
5) Storage is cheaper than ever.
6) Heartbleed has pointed out that exposure of confidential information, including private keys, is a realistic threat scenario (unfortunately, often SSL/TLS is the only protection of confidential information in transit). With the increased attention for the internals of OpenSSL and other SSL/TLS implementations, the chance of another "Heartbleed" incident happening soon has increased.
Hence, IMO the chance of "interested third parties" recording SSL/TLS encrypted traffic has increased, waiting for leaked private keys (or other vulnerabilities) to fall into their hands.
PFS comes with a price (performance, configuration questions, testing), but helps mitigating this risk.
Preferably you conduct your own risk assessment (the impact in particular), depending on your application and users. If you don't know how to do that, or don't have the time, then probably (hopefully) you don't have a high-risk application. In that case, don't bother implementing PFS.
However, if you are reading this text, you are probably interested in security and may have a high-risk application. In that case, if you don't know how to conduct a risk assessment or don't have the time, you'd better follow best current practice. Which is to enable PFS and configure your server such that PFS is preferred (and implement other measures, such as HSTS). If you keep non-PFS cipher suites enabled (typical), clients that do not support PFS, or do not wish to use PFS, still have the option to use non-PFS cipher suites.
Anonymous
Aug 13th 2014
1 decade ago
As a slight tangent, a recent OWASP podcast had an interview with the author of o-saft (https://www.owasp.org/index.php/O-Saft) which is another SSL scanning tool that goes well beyond simply listing the ciphers - certainly well beyond my limited knowledge of SSL. Just thought I'd throw that out there as it seems to be a good tool to have in addition to the nmap scripts.
Doug O'Leary
Anonymous
Aug 23rd 2014
1 decade ago
What is limited is the overall string length usable in the policy editor.
I dont know whether the string length usable in the registry entry
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002]
"Functions"="..."
is limited too, but I dont think so.
Fortunately there is no need at all to use this policy to reorder the
cipher suites, and there is no limit I'm aware of for the number of
cipher suites.
Get the script <http://home.arcor.de/skanthak/download/NT6_PFS.INF> and "install" it, then reboot and visit <https://www.ssllabs.com/ssltest/viewMyClient.html> with Internet Explorer.
Anonymous
Aug 27th 2014
1 decade ago