While security is on everyone’s mind, some organization with higher than usual security requirements have had some concerns regarding the encryption used in web-based transactions. Everyone knows that SSL encryption is pretty much the default for any web-based connection that requires security, but SSL itself is about much more than simply “have it/don’t have it”.
Those who deal a lot with security know that encryption is comprised of multiple parts. There is the protocol, such as TLS version 1, version 1.1 or 1.2; there’s the Cipher, which can include DES, Triple DES, RC2, RC4 and others; there’s the hash, which could be MD5 or SHA. For the cipher itself, one could have preference for a key length, which could be as short as 40 bit, or much longer. In the world of security, we refer to a combination of the above as a “Cipher Suite”.
Any software that supports encryption comes with a pre-configured set of supported suites, and some support more than others. For example, Windows 2008 and Window Vista included a whole slew of new protocols, making them better-built for the security-conscious organization. One topic that has come up recently is related to Windows support for Perfect Forward Secrecy. Perfect Forward Secrecy, or PFS for short, is the ability of certain encryption protocols to provide better security by using unique session keys that are not derived from the server’s private key. I won’t go into detail here, as PFS is well documented (for example, Vincent Bernat’s blog discusses it in detail http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html ), but this brings up the question “How can I take advantage of this awesome thing?”
Before we answer that, we should clarify that just because it’s more secure doesn’t automatically make it “better”. More security, you see, has a price, because the more complex negotiation process takes a toll on the computer’s resources, and the toll can be as high as 30%. If your server is highly utilized, then enabling PFS might saturate your CPU and require you to add another server to your array or pay more for resource usage if you are using a cloud-based service such as Azure. Another potential challenge with enabling PFS is that some older clients may not support it, leaving potential users reading error messages instead of your words of wisdom.
As I said, Windows 2008 and Vista added support for new stuff, and PFS is one of them. However, that doesn’t mean that it will automatically come into play. When a web client (such as Internet Explorer) and a web server (such as IIS) use encryption, the first step is negotiating the protocol. This is invisible to the naked eye, but if you examine a connection with a tool such as Network Monitor, you will see this:
What you see above is the 1st part of the security negotiation, and that’s a request coming from the client (the browser). In the bottom part you can see a list of Cipher Suites that the client supports, and this way it’s laying the ground rules for the server.
The server looks at this list, and selects the first protocol that it supports, and when it replies to the client (one packet later), we can see it like this:
This, by the way, is a standard SSL handshake for an IE10 browser talking to an IIS 8.5 server with an out-of-the-box configuration.
If we were to have a desire to limit this to only protocols that use PFS, we would need to either configure our clients to only support such suites, or configure our servers to only agree to use such suites. If you are a user who wants to enjoy the utmost security and does not mind that many websites will refuse to talk to your browser, you can do so using Steve Riley’s guide at http://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order-in-internet-explorer-7-on-windows-vista.aspx . Here, however, we want to focus on the server side.
Before we go on, we should clarify that PFS is an encryption technology, and not a name of a specific protocol. The name of the actual protocol is Diffie-Hellman Ephemeral, or DHE for short (Diffie-Hellman refers to the encryption experts Bailey Diffie and Martin Hellman who have single-handedly developed some of the most important security and encryption technologies in history). As you might have noticed above, the list of suites supported by IE includes quite a few variations with DHE:
In the screenshot above, the bottom 7 suites all use DHE, and that’s good news! This list might seem short, but keep in mind that the encryption system in Windows (known as Schannel) actually supports much more. The above list is only items that have been specifically enabled. For a full list of supported suites, visit http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757(v=vs.85).aspx
Since web browsers normally don’t prefer to use PFS, you might want to configure your server to enforce it. To do so, you can either tell your server to prefer suites with PFS, or you can go all-the-way and tell it to not accept any others. To do so, you can configure the list of supported protocols using the registry, as described in the following article: http://support.microsoft.com/kb/245030. Another option, which is quite easier, is to use IIS Crypto, a publicly available free tool by Nartac Software (https://www.nartac.com/Products/IISCrypto/Default.aspx). With IIS Crypto you can easily select which protocols, hashes, ciphers and key-exchanges are available for Schannel (and therefore IIS) to use, and you can also control the pecking order that affects the selection process:
Once you make changes to this, you can use Netmon to track the negotiation, and observe the suite that was used:
One last thing to keep in mind is that different clients, even if they do support PFS, may not support the same combination of encryption elements (that comprise a Cipher Suite, that is) and so if you are making changes to this configuration, make sure you test various browsers extensively, including various versions of these browsers. We’re sure you don’t want to get a nasty from that guy in accounting who still uses Internet Chameleon…right?!