TrustWave's vulnerability scanner fails a scan due to a Windows 10 machine running RDP:

Block cipher algorithms with block size of 64 bits (like DES and 3DES) birthday attack known as Sweet32 (CVE-2016-2183)

NOTE: On Windows 7/10 systems running RDP (Remote Desktop Protocol), the vulnerable cipher that should be disabled is labeled ‘TLS_RSA_WITH_3DES_EDE_CBC_SHA’.

Using IIS Crypto (by Nartac), I tried applying the "Best Practices" template as well as the PCI 3.1 template, however both of them includes the insecure cipher (TLS_RSA_WITH_3DES_EDE_CBC_SHA):

CipherScreen

If I disable this cipher, RDP from this computer to many Windows stations stops working (it still works to some 2008 R2 and 2012 R2 servers). The RDP client simply gives, "An internal error has occured" and the event log:

A fatal error occurred while creating a TLS client credential. The internal error state is 10013.

I checked the server event log of one of the servers and see these two messages

An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.

The following fatal alert was generated: 40. The internal error state is 1205.

How can I fix the security vulnerability without breaking outgoing RDP?

Or, if the above is not possible, is there something that I can do on each RDP host that I can no longer connect to that handles it on that end?

--- Update # 1 ---

After disabling TLS_RSA_WITH_3DES_EDE_CBC_SHA on the Windows 10 machine, I tried connecting to several RDP hosts (half of them failed with "An internal error..."). So I compared one of these hosts that I can connect to against one that I cannot connect to. Both are 2008 R2. Both have the same RDP version (6.3.9600, RDP Protocol 8.1 supported).

I compared the TLS protocols and ciphers by using IIS Crypto to do "Save Template" on their current settings so that I could compare the template files. They were identical! So whatever the issue is does not seem to be a matter of a missing chipher suite on the host. Here is a screen shot from Beyond Compare on the files:

Cipher compare

What could be different between the two RDP hosts that causes this issue and how to fix it?

  • Can you use NetMon or Wireshark to capture the client hello/server hello in order to see what cipher suite is actually being negotiated when the connection fails, versus when it succeeds? – Ryan Ries Nov 4 '16 at 18:35
  • @RyanRies: Already did, but it never gets to the actual TLS handshake. The client sends a "TPKT, Continuation" package and the server responds with "RST, ACK." – Zek Nov 4 '16 at 18:55

IIS Crypto has the option to set both the server side (incoming) and client side (outgoing) options. There are a handful of ciphers you need to leave enabled on the client side for compatibility.

To do what you want I'd personally go with the following:

  • Apply 3.1 template
  • Leave all cipher suites enabled
  • Apply to both client and server (checkbox ticked).
  • Click 'apply' to save changes

Reboot here if desired (and you have physical access to the machine).

  • Apply 3.1 template
  • Leave all cipher suites enabled
  • Apply to server (checkbox unticked).
  • Uncheck the 3DES option

Reboot here should result in the correct end state.

Effectively you only want to disable 3DES inbound, but still allow the outbound use of said cipher suite.

  • That sounds promising! However disabling 3DES 168 seems to have been a mistake - I can no longer connect to it . Once I have gotten this handled, I will try just disabling the cipher on server-side only and report back / accept the answer. – Zek Nov 4 '16 at 19:13
  • I tried your suggestion: 1) Apply "Best Practices" and apply to both server & client, then 2) Uncheck the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher and the "Set Client Side Protocols" and apply again, then of course reboot. The issue RDPing from this machine still persists. Additional suggestions are welcome. – Zek Nov 4 '16 at 20:04
  • 1
    @Zek strange... I've used the exact same technique and have it work. – Tim Brigham Nov 4 '16 at 20:05
  • @Zek I just realized I made a major mistake in how I wrote that up. I'll update accordingly. – Tim Brigham Nov 4 '16 at 20:07
  • I tried this. 1) Select the 3.1 template + leave all cipher suites as-is + "Set Client Side Protocols" enabled + check TLS 1.0 (SQL, etc. breaks w/o TLS 1.0) + Apply & reboot. 2) Select the 3.1 template + leave all cipher suites as-is + "Set Client Side Protocols" unchecked + uncheck 3DES + check TLS 1.0 + Apply & reboot. I can no longer connect, "An internal error has occurred" (I think the server must support 3DES). I am connecting from a Windows 10 machine. – Zek Nov 4 '16 at 20:35

I had same issue, installing KB3080079 patch on server enables support for tls 1.1 and 1.2.

Note that for windows 7 clients you will have to install rdp client update (KB2830477), otherwise only windows 8+ will be able to connect.

  • 1
    I just double checked and those updates are already installed (I believe they have been included in the standard Windows update for some time already), so that is not the issue. – Zek Nov 7 '16 at 15:08

Edit (2018-09-26): I've discovered that disabling 3DES on 2012R2 does NOT break RDP but it DOES break on 2008 R2. The options supported appear to be different between the kernels.


I'll share my answer from a TechNet thread but first BLUF:

Serverfault conclusion: Most likely you have some other difference in between the systems. You're connecting between different OS versions, one system has FIPS enabled and the other does not, or you have different cipher restrictions in place under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers. I would certainly enable the SCHANNEL logging on the system that does work to determine which cipher is in use. Would love to hear back if you somehow got RDP to work with an alternate cipher.

Copy of post:

We got it to work!

Apparently 2008 and 2012 have syntax issues and the 2008/7 requires a trailing /168. 2012/8.1/10 does not.

the key on 2008 looks like this: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168

And the key on 2012 looks like this: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168

I can confirm that use of "Triple DES 168/168" DOES NOT disable 3DES on the system. You can prove this to yourself with a protocol scanner (like Nessus) or by enabling SCHANNEL logging:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "EventLogging"=dword:00000007

You will then have events in the SYSTEM log for example;

An SSL client handshake completed successfully. The negotiated cryptographic parameters are as follows.

Protocol: TLS 1.0 CipherSuite: 0x2f Exchange strength: 1024

For me the result is 0xa which Google reveals as TLS_RSA_WITH_3DES_EDE_CBC_SHA.

When I use "Triple DES 168" (without the /168), the System event ID 36880 does not appear and the RDP session is blocked.

Per the article: System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing

Remote Desktop Services (RDS) For encrypting Remote Desktop Services network communication, this policy setting supports only the Triple DES encryption algorithm.

Per the article: "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" security setting effects in Windows XP and in later versions of Windows

This setting also affects Terminal Services in Windows Server 2003 and in later versions of Windows. The effect depends on whether TLS is being used for server authentication.

If TLS is being used for server authentication, this setting causes only TLS 1.0 to be used.

By default, if TLS is not being used, and this setting is not enabled on the client or on the server, the Remote Desktop Protocol (RDP) channel between the server and the client is encrypted by using the RC4 algorithm with a 128-bit key length. After you enable this setting on a Windows Server 2003-based computer, the following is true: The RDP channel is encrypted by using the 3DES algorithm in Cipher Block Chaining (CBC) mode with a 168-bit key length. The SHA-1 algorithm is used to create message digests. Clients must use the RDP 5.2 client program or a later version to connect.

So both of these support the idea that RDP can only utilize 3DES. However, this article suggests a larger range of ciphers is available: FIPS 140 Validation

The set of cryptographic algorithms that a Remote Desktop Protocol (RDP) server will use is scoped to: - CALG_RSA_KEYX - RSA public key exchange algorithm - CALG_3DES - Triple DES encryption algorithm - CALG_AES_128 - 128 bit AES - CALG_AES_256 - 256 bit AES - CALG_SHA1 - SHA hashing algorithm - CALG_SHA_256 - 256 bit SHA hashing algorithm - CALG_SHA_384 - 384 bit SHA hashing algorithm - CALG_SHA_512 - 512 bit SHA hashing algorithm

Ultimately it's not clear whether RDP can support non-3DES protocols when FIPS mode is enabled but evidence would suggest it doesn't.

I see no evidence that Server 2012 R2 would function differently from Server 2008 R2, however it does seem that Server 2008 R2 was based around FIPS 140-1 compliance and Server 2012 R2 follows FIPS 140-2 so it's entirely possible that Server 2012 R2 supports additional protocols. You'll note the additional protocols in the FIPS 140 Validation link.

In conclusion: I don't think Server 2008 R2 can support RDP in FIPS mode with 3DES disabled. My recommendation is to ascertain whether your system meets the conditions for a SWEET32 attack (more than 768GB sent in a single session) and whether disabling 3DES is worth removing RDP capability. Other utilities exist to manage servers beyond RDP especially in a world where virtualization is highly commonplace.

Apparently 2008 and 2012 have syntax issues and the 2008/7 requires a trailing /168. 2012/8.1/10 does not.

the key on 2008 looks like this: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168

**Great find i had the exact same issue on some windows 2008 R2 domain controllers, oddly my member 2008R2 servers seem ok ... and my 2012R2 servers work fine as well. Need to crack on decomming those older DC's :)

  • On my version of 2008R2 setting does not require adding 168 and accepts the same syntax as Windows 2012 registry. Just FYI if registry setting on 2008 did not work for you – Gregory Suvalian Aug 14 at 22:36

protected by Community May 3 '17 at 15:44

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.