3DES/FIPS 140-2/RDP Hotfix

In the past I’ve written a blog about the issues my company encountered when we disabled 3DES on our Windows 2008 R2 systems. Since we are obligated to also use FIPS 140-2 for compliance reasons the combination of disabling 3DES, and having FIPS140-2 enabled would break remote desktop functionality. Basically it came down to RDP using hardcoded 3DES when FIPS140-2 was also enabled. Needless to say RDP would stop functioning when you disable the one thing it could use. When the sweet32 vulnerability came along we had to make a choice, do we want to be secure or do we want to be able to remotely connect? Unfortunately since disabling 3DES is a system wide setting it’s not possible to differentiate between protocols. Leaving us stuck in between a rock and a hard place. Last option was to file a case with Microsoft.

It took us several conversations with Microsoft support, providing evidence and creating a business case for the Windows product group to determine the potential impact. One of the challenges we faced was that Windows 2008 R2 has been out of mainstream support for a couple of years now. So any change on this level would require the product group to agree upon a design change, which is very rare in these kind of situations. After a few month’s they agreed and we eventually got a preview fix that worked like a charm!

As of today I’m glad to be able to announce that a permanent fix has been released. As it’s a platform fix, bound to the operating system it will be included in the Microsoft update cycle of next month. My Microsoft representative has promised that an individual KB will be released soon describing the specific issue and solution. I’ll update this post when it becomes available.

A current hotfix is already included in the preview for September 2017, which you can get here:
https://support.microsoft.com/en-us/help/4038803/windows-7-update-kb4038803

Or get it from the catalog:
http://catalog.update.microsoft.com/v7/site/Search.aspx?q=KB4038803

On a personal note, I would like to extend my gratitude to Microsoft support for the excellent push they did towards the product group convincing them on the necessity for this fix and working with me throughout this endeavor. My first experience being a customer instead of a Microsoft employee was a very pleasant experience!

Custom RDP Certificate on Windows Server 2012 R2

Ever since Windows 2012 the Remote Desktop host tool has been removed from the system, making it more difficult to set a custom certificate. When you’re in a domain context it’s more likely that you will use GPO’s and domain related tools to configure your system, but in my work environment I deal with stand-alone systems, making it a bit harder to manage. During one of my security scans with our vulnerability tool it started complaining about self-signed certificates. Simply removing the certificates from the local computer store and using WMI to update the system is fairly easy, but after doing the same trick twice, it gets annoying so I decided to write a PowerShell script to handle the task of setting the correct certificate.

My script has a couple of parameters that you can use:

Set-RDPCertificate.ps1 -Hash <string> [-Delete] [-Terminalname <string>] [<CommonParameters>]
Set-RDPCertificate.ps1 -listCerts [<CommonParameters>]
Set-RDPCertificate.ps1 -ListCurrent [<CommonParameters>]

  • Hash: This is the default input parameter, expects a 40 character string value
  • Delete: Delete the current certificate from the local store after setting the provided hash value.
  • Terminalname: If you changed the default RDP-TCP connection name you can enter it here, not providing the parameter will result in using the default name.
  • Listcert: Lists the certificates in the personal store of the local computer.
  • ListCurrent: Lists all certificates in the personal store of the local computer.

Download the script from here. Version 1.1.

Challenges with Disabling 3Des

With the discovery of the sweet32 vulnerability (more at sweet32.info) in 3Des and 64-bit block ciphers in general, we had to see if it was possible to disable 3Des on our devices. You could be thinking, why have it enabled in the first place? Well, on Windows systems it’s enabled by default if you don’t take necessary steps and 3Des/168 is still a valid cipher in FIPS 140-2, which we must be compliant with. Disabling 3Des however is easy enough, handling the troubles afterwards is not. To disable 3Des add the following Registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168\Enabled (DWORD) = 0

This disabled the following cipher suites:

SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Source: https://support.microsoft.com/en-us/help/245030/how-to-restrict-the-use-of-certain-cryptographic-algorithms-and-protocols-in-schannel.dll

During our tests on Windows Server 2008 R2 and Windows Server 2012 R2, the outcome was very different. Since we also disabled TLS 1.0 at the same time we ran into a few issues on 2008 R2. Just mind the following:

  • Make sure that you install KB308079, to add support for TLS 1.1 and 1.2 for RDP. HTTP already supports TLS 1.1 & 1.2
    https://support.microsoft.com/en-us/kb/3080079
  • Explicitly enable TLS 1.1 and TLS 1.2 in the registry of Windows Server 2008 R2 otherwise stuff will break. In our case, we couldn’t bind a certificate to a web site.
  • If you disable 3Des and have FIPS 140-2 enabled this will break RDP on Windows 2008 R2. We currently have a support case with Microsoft to see if this can be fixed (more info when it becomes available *).

* June 2017 – A hotfix for Windows Server 2008 R2 will be made available that fixes this specific issue.

*July 2017 – After intensive testing of a private hotfix no negative side effects could be found. A hotfix is scheduled to be released at the end of September 2017.

These are the major challenges we ran into. On Server 2012 R2, these issues didn’t occur. Just because I wanted to know what was going on under the hood I spend a day creating different scenario’s and monitoring results to see which ciphers would be used. I’ve listed the results below. Hopefully someone can make use of this information.

Scenarios

The following scenarios consists out of testing a Windows 7 client making a RDP or HTTP connection to a Windows 2008 R2 or Windows 2012 R2 server. Unless otherwise stated, the Windows client and server are patched with all security updates available. No additional updates have been installed. I would recommend against this setup in production, yet I know many organizations are reluctant to install additional updates in their environment. The conclusion of these tests shows that changes to the OS would have been covered if you install recommended updates as well. Security features, such as TLS, FIPS and 3DES are disabled on the server, not on the client.

Windows 7 & Windows Server 2008 R2

Protocol: Remote Desktop Protocol

  • Default (No changes to the Operating System): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • FIPS 140-2 Enabled: TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Enabled): TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Disabled): No connection
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on Windows 7: TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on Windows 7: No connection
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on Windows 2008 R2: TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on Windows 2008 R2: No connection
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on both: TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on both: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on both: No connection
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on both: TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.2

Observation: As you can clearly see in the results above, Windows 2008 R2 with FIPS 140-2 always connects with TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.0 even if you have disabled TLS 1.0. Disabling 3DES kills the RDP connection entirely.

Protocol: HTTP

  • Default (No changes to the Operating System): LS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • FIPS 140-2 Enabled: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Enabled): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on Windows 2008 R2: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on Windows 2008 R2: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on both: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on both: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on both: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on both: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2

Observation: HTTP does a far better job in selecting the correct ciphers, with or without FIPS140-2 enabled it selects the highest suite available. However, without any adjustments it prefers TLS 1.0 over 1.2 even when kb3080079 is installed. Please be aware that on Server 2008 R2 TLS1.1 & 1.2 are explicitly enabled in the registry.

Windows 7 & Windows Server 2012 R2

Protocol: Remote Desktop Protocol

  • Default (No changes to the Operating System): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • FIPS 140-2 Enabled: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Enabled): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Disabled): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Enabled) & kb3080079 on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Disabled) & kb3080079 on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2

Observation: When connecting to Windows Server 2012 R2 over RDP, the protocol still seems to have mind of it’s own. Disabling TLS1.0 on the server side seems to be ignored until you have installed kb3080079 on the Windows 7 box. After installing that update TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2 is the preferred cipher regardless of FIPS140-2 compliancy.

Protocol: HTTP

  • Default (No changes to the Operating System):
    FIPS 140-2 Enabled: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Enabled): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Enabled) & kb3080079 on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Disabled) & kb3080079 on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2

Observation: HTTP again is very consistent in selecting it’s cipher suite. Selecting FIPS140-2 compliancy has no negative or positive effect on the selection.