How to Enable and Disable SSL / TLS Versions on Forefront TMG

In my previous article What everyone should know about HTTPS, SSL, TLS and Certificates, I covered the basics of cryptography protocols and I touched lightly on the point that SSL and TLS are generally interchangeable terms referring to the same thing.

In this article I will go a little deeper into the differences, and explain how to enable and disable SSL / TLS versions on Forefront TMG to ensure your internal sites are running the latest and greatest cryptographic protocol version.

The Heartbleed Vulnerability on Forefront TMG

The recent OpenSSL Heartbleed vulnerability identified a critical issue with any Unix / Linux appliance, device, web server or firewall as they all share common libraries. Any system using OpenSSL version 1.0.1 through to 1.0.1f is vulnerable.

Fortunately, Microsoft have their own crypto stack and do not rely OpenSLL at all. As such none of the Microsoft products are vulnerable. This includes Forefront TMG and any web site that you reverse proxy through it. To double check, you can use the online test from SSL Labs https://www.ssllabs.com/ssltest/

One thing to keep in mind is that Heartbleed only affects TLS and not SSL. If you are not sure what the difference is, keep reading.

The SSL / TLS Timeline

SSL is essential the predecessor to TLS. As you would expect, TLS has taken the basic principles and functionality of SSL and improved upon them.

Most people, including a large portion of IT pros, are surprised to hear that there is something other then SSL that does the same thing. When you suggest turning off SSL 2.0, it is often met with some caution and resistance.

To put things into perspective, take a look at the timeline for SSL and TLS versions and pay attention to the interval between protocol iterations.

• SSL 1.0 (Never publicly used)
• SSL 2.0 (1995)
• SSL 3.0 (1996)
• TLS 1.0 (1999)
• TLS 1.1 (2006)
• TLS 1.2 (2008)

Notice how SSL 2.0 only had about a year before it was superseded almost 20 years ago?!

SSL / TLS Browser Support

In practice, the majority of public web sites are using TLS. Browser support for TLS has followed closely behind the protocol release itself.

The first versions of browsers that added support for TLS are:

• Internet Explorer 6
• Firefox 1
• Chrome 0
• Opera 5
• Safari 4

We are now at the point where all of these browsers in their latest version support TLS 1.2

Which SSL / TLS Version Gets Used?

During the SSL handshake process, the browser and the server elect which protocol to use. The default behavior is to always use the highest version that is supported on both sides. This automatically ensures the highest level of security.

You can influence this process by selectively enabling or disabling the setting on the client side.

In Internet Explorer the settings are located in Internet Options | Advanced. Scroll down to the Security section to find the various checkboxes to enable or disable the protocols.

Checking your Web Servers

A great way to get a very thorough evaluation of your secure web site is to scan the site with the Free SSL Server Test from SSL labs.

The scan only takes about a minute to complete and provides you with a nice set of results. Under the configuration section, the protocols and associated Cipher Suites are listed.

If you look at the protocols from this scan you can see that SSL 2.0 is supported but TLS 1.1. and TLS 1.2 are not.

This scan was run against a Forefront TMG server that reverse proxies a Windows Server 2012 R2 IIS server. By default 2012R support SSL 3.0 and up. The reason the scan only detects up to TLS version 1.0 is because Forefront TMG itself is limited to those protocols.

How to Enable and Disable SSL / TLS Versions

Support for the newer cryptographic protocols such as TLS 1.1 and 1.2 are provided to Windows through the Security Support Provider Interface (SSPI) API. As you may expect for something as granular as this, it needs to be done through the registry.

• Open Regdit (Start | Run | Regedit)
• Navigate to the registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
• Here you will need to create a key for each of the cryptographic protocols. Create keys named TLS 1.0 and TLS 1.1
• Within each protocol key, create two sub keys. One named Client, the other named Server
• Within each of the Client and Server keys, create a DWORD with the name Enabled. A value of 1 enables the protocol where a value of 0 disables it.
• Within each of the Client and Server keys, create another DWORD with the name DisabledByDefault. A value of 0 enables the protocol (i.e. not disabled by default).

When you are done you should have entries that look like this You can also download and run this SSL TLS regfile or follow the steps from Microsoft directly:

• How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll
• How to disable PCT 1.0, SSL 2.0, SSL 3.0, or TLS 1.0 in Internet Information Services

Once the registry changes are made, you may need to restart your server. You can now re-run the SSL Labs test and you should get a better result.

Disabling SSL 2.0

While you were looking at the SSL 2.0 branch in the registry, you would have noticed en existing entry in the client node called DisabledByDefault. This is because SSL 2.0 has been deemed insecure and it is not recommended. As you can deduce from this, disabling SSL 2.0 on the server side would simply pull it inline with the default client configuration.

How to check SSL / TLS Versions in the browser

While browsing the Internet, you can check the client to see which protocol has been negotiated. To do this in Chrome:

• Browse to a secure site
• Click on the security padlock in the address bar
• Select the Connection tab
• The second section covers encryption

This is also handy if you would like to check your internal web servers that are not published to the Internet, preventing the SSL Labs test to be used.

Conclusion

Disabling SSL 2.0 is something that can almost always be done safely. It is something that gets checked by all security and audit scanning tools, and getting a bad score for supporting a protocol that is simply not used anymore is unnecessary.

Enabling the newer, more secure protocols will allow browsers to make use of the better security when possible. If you look at the logs of your reverse proxy traffic with a tool such as Webspy Vantage you will notice that HTTPS makes up a significant percentage of your traffic. Providing access to better security protocols is something all Forefront TMG admins should seriously consider.