Disabling TLS 1.0 on your Windows 2008 R2 server – just because you still have one

Windows 2008 R2 server is a very popular distribution of Windows that has been used time and time again to power servers running ASP.net websites – either on the Internet or on Intranets. Although this Windows version has somewhat aged from 8 years ago, I still tend to see quite a lot of these installs around, and happen to have some myself, which are running for my bookmarking service www.linqto.me .

If you have been reading about all the security problems creeping up on the internet lately, you should have come across words like Heart Beat Bleed, Poodle and other such vulnerabilities that are problematic when encrypting an HTTP connection between a client and a server. For the record, when it comes to securing a connection between client and server for HTTP related exchanges, there is an entire list of protocols we can chose from (or rather the client and server have to agree on). The list, with the dates these were released should give you an idea of how old some of these technologies are:

    SSL (short for secure sockets layer) version 1, 2 and 3 – initial specs for these came out in 1995 – that is more than 20 years ago!

    TLS (short for transport layer security) version 1.0 – came out in 1999

    TLS version 1.1 – came out in 2006

    TLS version 1.2 – came out in 2008

SSL protocols should not be used any more, as they are full of known vulnerabilities. TLS 1.0 has had its share of vulnerabilities, and more and more organizations are beginning to turn this off as a choice for negotiation of encryption between client and server. I recommend that you do too, and use more secure versions like TLS 1.1 or 1.2 if possible. If you are already on this blog post, chances are you are trying to do just this – turn off TLS 1.0 on your Windows 2008 R2 server. Which should be easy to do… or not, so keep reading.

Steps to turn off TLS 1.0 on a Windows 2008 R2 server.

There is a Microsoft Support Knowledge base article that discusses this in some detail and also recommends that you download a 'Fix it for me' automated repair tool. The article in question is the following: https://support.microsoft.com/en-us/kb/187498 . However, there are a couple of problems and loopholes in the article above, so I want to go through them in some detail.

  • The first is that the 'Fix it for me' automated installer is no longer available. Microsoft has decided to retire this technology, hence also stopping you from having an automated solution to disable TLS 1.0 and leave only TLS 1.1. and 1.2
  • The manual solution indicates that you should change some registry keys, but I have found this to be somewhat incomplete, because just changing the indicated keys will turn off all TLS communications, including TLS 1.1 and 1.2 – which is not what you want when you are running a site that has HTTPS bindings.
  • The article never mentions that if you are connecting to your server via Remote Terminal Service (or Remote Desktop), you will also be cutting the branch out from under your feet – these methods of communication with a remote server actually rely on TLS 1.0, and once it is disabled you will not be able to connect to your server any more, not via Remote Desktop anyways. If your server is in a remote location or data-center, that can become a serious problem that can cause you much grief and downtime.

To correctly disable TLS 1.0 follow the steps below:

  • Install the Microsoft patch that allows you to continue using Remote Terminal Services or Remote Desktop after TLS 1.0 is disabled: https://support.microsoft.com/en-us/kb/3080079 . This should be the first step on your list, as missing this patch will leave you unable to connect to your server after disabling TLS 1.0.
  • Disable TLS 1.0 from the registry, using the registry editor. This one requires several sub-steps which you have to go through:
    • Open the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\ registry key

    • If a TLS 1.0 key is present go inside, if not you will have to create a new Key and name it 'TLS 1.0'

    • If the TLS 1.0 key exists, you should also have a key called 'Client' and one called 'Server' underneath, if not you will have to create them as you did in the previous step:

    • The next steps will have to be done both for the 'Client' and 'Server' keys as we want to disable TLS 1.0 when the OS is acting as a server (typically in the case of a website), but also when it is acting as a client and connecting to other resources that require secure connections. Go into the 'Client' key and create a DWORD (32 bit) entry and call this 'Enabled' and set its value to 0. Then repeat, and create a new DWORD (32 bit) entry for the 'Server' key and call it 'Enabled' and set the value to 0. This will disable TLS (all versions) for both client and server.

    • Now we have to enable versions 1.1 and 1.2 of TLS. For this, we need to create new keys called 'TLS 1.1' and 'TLS 1.2' underneath the 'Protocols' key.

    • For each of the TLS 1.1 and TLS 1.2 keys, you should also create a 'Client' and a 'Server' key, as shown in the screenshot below:

    • Once the key structure is created, you can proceed to creating a DWORD (32 bit) entry called 'DisabledByDefault' and set its value to '0' in each of the four keys: TLS 1.1/Client, TLS 1.1/Server, TLS 1.2/Client and TLS 1.2/Server.

I have created a small export of the registry from my server which I am pasting below as text for reference:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]

Time to restart your server following these changes and you will see that the next connection attempt to resources that require https (secure connections) for your sites will be using TLS 1.1 or TLS 1.2. Hope this helps you secure your servers and dodge some nasty security vulnerabilities.

Paul Cociuba
follow what I post on www.linqto.me


Following the initial writing of this article, I became aware of another issue with TLS 1.1 and TLS 1.2 when using FTP secure on the IIS 7.5 / Windows 2008 R2 server. Read more below to find out about the issue.

Consider the following scenario:
- you have performed the changes listed above for you IIS server to disable TLS 1.0 but you also have and FTP server that is running on the same box.
- the FTP server is configured to use either implicit or explicit FTP secure (or FTPS) connections for incoming clients.

When you try to connect to the server and list the files for the various folders you have access to, everything will work perfectly. However, when you try and upload a new file to the FTP server (in my case I was using FileZilla as a client), you will see the upload progressing until you reach 100% after which the FTP client will show a message indicating that the upload has failed. If you are curios enough to consult the FTP logs, you will see something like the below log snippet for the file that we are trying to upload:

#Software: Microsoft Internet Information Services 7.0
#Version: 1.0
#Date: 2017-01-08 14:16:49 #Fields: date time c-ip cs-username s-ip s-port cs-method cs-uri-stem sc-status sc-win32-status sc-substatus time-taken x-session x-fullpath

2017-01-08 14:05:57 LINQTO\Administrator 2001 DataChannelOpened - - 0 0 0 a8965daf-855c-4ef8-b43c-b5376069a5d7 -
2017-01-08 14:05:57 LINQTO\Administrator 2001 DataChannelClosed - - 2148074264 0 0 a8965daf-855c-4ef8-b43c-b5376069a5d7 -
2017-01-08 14:05:57 LINQTO\Administrator 990 STOR SampleDocument.doc 550 2148074264 0 141 a8965daf-855c-4ef8-b43c-b5376069a5d7 /SampleDocument.doc

Notice that the status code for the upload request (STOR) is 550. According to the FTP status codes (https://linqto.me/FtpStatus) this means 'Requested action not taken. File unavailable (for example, file not found, or no access)' . The interesting status code is the sc-win32-status code for the request which is 2148074264 -  which is 0x80090318 in hexadecimal. This error translates tohe SSL Error code SEC_E_INCOMPLETE_MESSAGE, and the description for that is the error text that you are seeing: "The supplied message is incomplete. The signature was not verified. "

There is a bug in the FTP 7.5 server for IIS when using TLS 1.1 or 1.2 which causes this error code and all uploads (large and small) to fail. The knowledge base article documenting this is here: https://support.microsoft.com/en-us/kb/2888853 . The same article also contains the hotfix download to fix the issue.