Share via

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

  • Article

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]
[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]
"DisabledByDefault"=dword:00000001
[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]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"Enabled"=dword:00000000
[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]
"DisabledByDefault"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"DisabledByDefault"=dword:00000000
[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]
"DisabledByDefault"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000

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

Post-Scriptum:

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 77.129.228.80 LINQTO\Administrator 95.170.83.45 2001 DataChannelOpened - - 0 0 0 a8965daf-855c-4ef8-b43c-b5376069a5d7 -
2017-01-08 14:05:57 77.129.228.80 LINQTO\Administrator 95.170.83.45 2001 DataChannelClosed - - 2148074264 0 0 a8965daf-855c-4ef8-b43c-b5376069a5d7 -
2017-01-08 14:05:57 77.129.228.80 LINQTO\Administrator 95.170.83.45 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.

Comments

  • Anonymous
    February 14, 2017
    SSL 3.0 should also be disabled. It isn't pictured here? Just curious.
    • Anonymous
      May 04, 2017
      By default SSL 3 support (the ancestor of TLS) is already disabled in browsers (Internet Explorer and the like). If not, you can follow the registry key set changes outlined in this article to disable it on the server side:https://technet.microsoft.com/en-us/library/security/3009008.aspx
      • Anonymous
        June 26, 2017
        Browsers, yes, but browsers aren't the only thing that connect to web servers. There are a ton of .NET and other web applications out there and given that SSL 3.0 has been a default in .NET until fairly recently and leaving it enabled on your server still makes the attack possible, it should be disabled server side too, which prevents the attack from even being possible. POODLE is a MITM attack, so even if your browser doesn't have SSL 3.0 enabled by default, to successfully launch a POODLE attack, I need to have some control over the client request, which would mean I likely have control of the client computer and can just enable SSL 3.0. It just seems odd to me that you would list the steps to disable SSL 2.0 and TLS 1.0 and leave SSL 3.0 enabled, which is what the above pictures.
        • Anonymous
          August 11, 2017
          Just duplicate the steps above with a SSL 3.0 key, client and server subkeys, and the DisabledByDefault DWORD set to 1 and that should take care of SSL 3 as well.
  • Anonymous
    May 28, 2017
    After Disabling TLS1.0 on 2012 R2 unable to take RDP. Is it bug?
    • Anonymous
      October 03, 2017
      What client are you trying to connect with? If you are using the RDP client that is included in Windows 7 by default, it can only do TLS 1.0. You will need to upgrade your client to RDP 8, which can use TLS 1.2
  • Anonymous
    July 26, 2017
    First of all thank you for providing such a detailed and comprehensive document.Please confirm can we do the same steps for disabling TLS 1.0 on Microsoft Windows 2012 R2.Thanks in advanced.
    • Anonymous
      October 03, 2017
      Yes, you can follow the exact same procedure and modify the registry keys.
  • Anonymous
    November 17, 2017
    Is it applicable for Windows server 2008 SP2. because I have tried same steps as per this article but RDP is not working. I have installed the update KB4019276 and performed registry changes as per below link.https://support.microsoft.com/en-us/help/4019276/update-to-add-support-for-tls-1-1-and-tls-1-2-in-windows-server-2008-sPlease suggest for Windows Server 2008 SP2
    • Anonymous
      December 11, 2017
      The comment has been removed
  • Anonymous
    December 05, 2017
    Hi, If TLS1.0, TLS1.1 is not present, then does it mean they are enabled by default?
    • Anonymous
      December 11, 2017
      Depends which keys: the /client keys underneath each of the protocols indicate if the server can use TLS 1.0, 1.1 and 1,2 as a client when connecting to some other service (think of your website connecting to a backend service). In this case, yes... if the keys are missing these are enabled. The issue is to understand that once you create the DisabledByDefault key underneath TLS 1.0, it will also disable 1.1 and 1.2 for that machine both acting as a client and a server.
  • Anonymous
    February 04, 2019
    Hello and thanks for this great article. When I go to install the patch from https://support.microsoft.com/en-us/kb/3080079 I get a message stating that "The update is not applicable to your computer" I am running Windows Server 2008 R2 with SP1. Can't find any info about this and cannot proceed with your instructions. Any idea?Thanks,Joe
    • Anonymous
      April 17, 2019
      Hello Joe,The message you receive is because one or multiple files that are brought in by the update in question (KB 3080079) are already at higher versions on your server than the versions contained in the KB. You can just proceed without installing the KB update in this case, since I suspect it has been incorporated in the Windows updates for Windows 2008 R2 server.Paul