In my blog Require 128-bit Encryption for HTTPS Traffic with ISA Server 2006 I posted a workaround for enabling Redirect all traffic from HTTP to HTTPS *and* Require 128-bit encryption for HTTPS traffic in a web publishing rule. However, what does that setting Require 128-bit encryption for HTTPS traffic really means and how does it work?
According to the ISA help file, the setting Require 128-bit encryption for HTTPS traffic means: Click to specify that HTTPS requests that do not use 128-bit encryption will be blocked. Hmm… does that mean that the ISA Server will refuse HTTPS requests if they are send over a secure channel (SSL/TLS) that uses a weaker encryption algorithm, or that a secure channel (SSL/TLS) will not be setted up in the first place when both parties don’t agree on a strong encryption algorithm?
To find it out, we have to watch the SSL/TLS handshake protocol with a sniffer like NetMon or Wireshark. Particular we are interested in the Client Hello and Server Hello messages used to negotiate the Cipher Suite, that is a list of key-exchange algorithms and Cipher Specs supported. Of course, this means that you need a basic understanding on how the SSL/TLS handshake protocol works. Some good resources to learn more about the SSL/TLS handshake protocol are:
Now that we know what to look for and assuming that we have a properly configured ISA Server with a sniffer enabled on the external interface, we also need a method to define which Cipher Suites will be offered by the client and/or will be accepted by the server during the SSL/TLS handshake. In that way we can determine how ISA Server will treat a none compliant client (or a bad guy). The key to the whole discussion here is the Microsoft Knowledge Base Article 245030 How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll. Take note that the SChannel is the heart of the Windows cryptographic mechanisms. Therefore ISA server rightly defers to Windows for all encryption. In other words, ISA server should just been seen as a consumer of the Windows SChannel stuff, not as the owner of it.
In the first scenario we use a standard Windows XP SP2 client and a standard ISA 2006 SE server (on Windows 2003 SP2) with the setting Require 128-bit encryption for HTTPS traffic enabled. Here is an excerpt of the SSL/TLS handshake:
If we go into the details of the Client Hello message (frame #4), we get the following information:
As you can clearly see, the Session ID is zero which means that a new connection for a new SSL/TLS session is being negotiated. Also, the client proposes 11 Cipher Suites to the server from which the server should choose one, normally one of the strongest. The Cipher Suite chosen by the server is then reported back to the client in the Server Hello message (frame #5-6) as shown in the figure below:
As you can see a strong cipher is chosen by the server. This completes the analyses of the SSL/TLS handshake in the context of this blog.
In the ISA logging you should find the following sequence of events:
In the second scenario we configure the client so that only weak ciphers are proposed to the server. To accomplish that we use KB245030 to disable the SChannel Ciphers RC2 128/128, RC4 128/128 and Triple DES 168/168 located under the HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL key in the registry. When we try now to access the exact same published web site as in the first scenario, IE gives the following error page:
This sounds good because we can’t access anymore that published web site as expected. However, due to the fact we get a specific error page “Error Code: 403 Forbidden”, we can assume that ISA reported the error code back to the browser. As a result the SSL/TLS session must have completed successful, otherwise no communication path was available between the browser and the ISA server to send that message. So, let’s verify that with the help of a network trace. Here is an excerpt of the SSL/TLS handshake:
If we go into the details of the Client Hello message (frame #6), we get the following information:
As you can clearly see, the Session ID is zero which means that a new connection for a new SSL/TLS session is being negotiated. Also, the client proposes now only 7 Cipher Suites to the server from which the server should choose one, normally one of the strongest. The Cipher Suite chosen by the server is then reported back to the client in the Server Hello message (frame #7-8) as shown in the figure below:
As you can see the server could not select a strong cipher because no one was offered. Thus a weak one was indeed chosen by the server to be able to report back the error page “Error Code: 403 Forbidden” to the client. Take note that no other data is allowed by the ISA server because the negotiated cipher didn’t fulfil the Require 128-bit encryption for HTTPS requirement.
In the ISA logging you should find the following sequence of events:
In the third scenario we additional configure the server so that only strong ciphers are accepted. To accomplish that we use again KB245030 to make sure that only the SChannel Ciphers RC2 128/128, RC4 128/128 and Triple DES 168/168 located under the HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL key in the registry are enabled. All other SChannel Ciphers should be disabled. When we try now to access the exact same published web site as in the first scenario, IE gives the following error page:
Again, this sounds good because we can’t access anymore that published web site as expected. However, due to the fact we get a generic error page, we can assume that the server actively refused the SSL/TLS session. As a result the Web Proxy component on ISA was never aware of that connection attempt. So, let’s verify that with the help of a network trace. Here is an excerpt of the SSL/TLS handshake:
If we go into the details of the Client Hello message (frame #8), we get the following information:
As you can clearly see, the Session ID is zero which means that a new connection for a new SSL/TLS session is being negotiated. Also, the client proposes again only 7 Cipher Suites to the server from which the server should choose one, normally one of the strongest. However, instead of responding with a Server Hello message, the server closes the TCP connection (frame #9-13). The obvious reason for this is that the client was configured to only propose weak ciphers and that the server was tuned to only accept strong ciphers. Thus no common Cipher Suite could be negotiated and therefore the SSL/TLS negotiation was aborted.
In the ISA logging you should find the following sequence of events:
In conclusion we can say that if the setting Require 128-bit encryption for HTTPS traffic is enabled then the Web Proxy component on ISA checks for every HTTPS request if the secure channel used to pass that request has a strong Cipher Suite (at least 128-bit encryption) as property. However, it does *not* prevent the setup of a secure channel with a weak Cipher Suite. If you want that level of control then the registry changes to limit the SSL/TLS Cipher Suites (KB245030) are the right answer. Take note that limiting the SSL/TLS Cipher Suites is a machine global configuration. Thus you can’t control that on the rule level.
We can debate about which approach is the best. Personally, I would like to see that a new Global HTTP Policy Setting was added to the ISA Server MMC (Configuration -> General) which gives us the choice to only enable the strong SSL/TLS Cipher Suites. Of course, when this new Global HTTP Policy Setting would be enabled then the Require 128-bit encryption for HTTPS traffic setting on the rule level should be automatically deactivated (greyed out).
HTH,
Stefaan