Share via

Perfect Secrecy in an imperfect world

  • Article

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 https://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:

clip_image002

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:

clip_image004

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 https://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:

clip_image005

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 https://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: https://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:

clip_image006

Once you make changes to this, you can use Netmon to track the negotiation, and observe the suite that was used:

clip_image007

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?!

Comments

  • Anonymous
    January 01, 2003
    Well done

  • Anonymous
    September 29, 2014
    So what settings do I need to have in the IIS Crypto program to achieve this?

  • Anonymous
    October 02, 2014
    Lost, Always make sure you backup the registry before to play it safe but after you have done that the way I see it is you launch IIS Crypto and either manually choose which Protocols, Ciphers, Hashes and Key Exchanges to use or you could just click Best Practices and have the program make the selections for you. Once you click Apply the program will make the registry changes for you after which you will need to reboot the server. For the program to work I believe the latest version needs .Net version 4 installed but I believe they have a .Net 2 version as well. Their website should tell you. Hope this helps.

    Take care, x

  • Anonymous
    November 24, 2014
    This is a really good article and would have been great if you included something like this to finish it off for those of us who don't understand cryptography as well as you do.

    https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy

    Enabling forward secrecy can be done in two steps:
    1.Configure your server to actively select the most desirable suite from the list offered by SSL clients.
    2.Put ECDHE and DHE suites to the top of your list. (The order is important; because ECDHE suites are faster, you want to use them whenever clients supports them.)
    Knowing which suites to enable and move to the top can be tricky, because not all browsers (devices) support all forward secrecy suites. At this point you may want to look for inspiration from those who are already supporting forward secrecy, for example Google.
    In the nutshell, these are some of the suites you might want to enable3 and push (close) to the top:
    •TLS_ECDHE_RSA_WITH_RC4_128_SHA
    •TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
    •TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
    •TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA