none
Disabling 3DES breaks RDP to Server 2008 R2 RRS feed

  • Question

  • During an update of our gold image for Server 2008 R2 I disabled 3DES via the registry to mitigate the SWEET32 birthday attack vulnerability.  The registry setting I used to disable 3DES is DWORD "Enabled" = 0 at path HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168.  The vulnerability was successfully mitigated, but I could no longer RDP to the server.  The following error message is displayed:  "This computer can't connect to the remote computer.  Try connecting again.  If the problem continues, contact the owner of the remote computer or your network administrator."  As it turns out, it doesn't matter whether the "Enabled" DWORD is set to 0 or 1 - RDP is broken either way.  It starts working again if I delete "Enabled", but this obviously then doesn't mitigate the vulnerability.  I tested this on multiple servers in our lab.  

    I should also mention that we are required to have "System Cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" set to Enabled.  If I disable this setting with 3DES disabled, RDP works.  So, it appears that having the FIPS setting enabled requires 3DES to also be enabled.  However, this is not the case on our Server 2012 R2 machines.  I've tested multiple servers in our lab with 2012 R2 installed and have been able to disable 3DES while keeping the FIPS setting enabled and have no issues RDPing the servers.  This is the desired configuration and result on 2008 R2.

    I've searched all over the internet and haven't been able to find a fix.  Any help is greatly appreciated.

    Wednesday, November 16, 2016 8:11 PM

Answers

  • 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.

    • Proposed as answer by Ian.Fuller Tuesday, January 10, 2017 10:25 PM
    • Marked as answer by r.mangan Tuesday, January 10, 2017 11:32 PM
    Tuesday, January 10, 2017 10:25 PM

All replies

  • Hi,

    Thanks for your post.

    Based on my research, after enabling the setting "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing", it 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.

    Please go through the following article to get more information:

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

    https://support.microsoft.com/en-us/kb/811833

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, November 17, 2016 9:15 AM
    Moderator
  • Thank you for your reply.  The article you provided led me to find another article with additional information that states the following:  

    https://technet.microsoft.com/en-us/library/jj852197(v=ws.11).aspx

    "This policy setting determines whether the TLS/SSL security provider supports only the FIPS-compliant strong cipher suite known as TLS_RSA_WITH_3DES_EDE_CBC_SHA, which means that the provider only supports the TLS protocol as a client computer and as a server, if applicable. It uses only the Triple Data Encryption Standard (3DES) encryption algorithm..." 

    However, the article says it's applicable to Server 2008 R2 and also Server 2012 R2 (among others).  This does help to explain why I can't RDP to our 2008 R2 machines when 3DES is disabled, but it doesn't explain why I'm not experiencing the same issue with our 2012 R2 machines.  Based on the information in the article, I shouldn't be able to RDP to 2012 R2 machines either.  This leaves me still somewhat confused, but I do appreciate your help with an answer about 2008 R2.

    Thursday, November 17, 2016 2:46 PM
  • Hi,

    Please check if you have installed the following KB:

    Update to add RDS support for TLS 1.1 and TLS 1.2 in Windows 7 or Windows Server 2008 R2

    https://support.microsoft.com/en-us/kb/3080079

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, November 21, 2016 6:18 AM
    Moderator
  • Yes, that KB is installed.  

    I also configured SCHANNEL logging to view details of the connection with different combinations of settings for FIPS and 3DES.

    1. FIPS disabled, 3DES disabled:  TLS 1.2 with TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028).

    2. FIPS disabled, 3DES enabled:  TLS 1.2 with TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028).

    3. FIPS enabled, 3DES enabled:  TLS 1.2 with TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa).

    4. FIPS enabled, 3DES disabled:  connection can't be established.

    On Server 2012 R2, TLS 1.2 with TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) is used with every combination of settings.  This makes it seem like there must have been an update to the list of ciphers allowed by the FIPS setting for 2012 R2 but not on 2008 R2.

    Monday, November 21, 2016 5:18 PM
  • Hi,

    Thanks for your update.

    Maybe checking the ciper suite order on 2008 R2?

    Server 2008 R2 Cipher Suite Order - Strongest to Weakest                                 

    https://social.technet.microsoft.com/Forums/en-US/be98bda4-f373-4005-a7fd-b9ef6bb81c62/server-2008-r2-cipher-suite-order-strongest-to-weakest?forum=winserversecurity

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, November 24, 2016 11:10 AM
    Moderator
  • Hi,

    Just checking in to see if the information provided was helpful. Please let us know if you would like further assistance.

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, November 29, 2016 3:20 AM
    Moderator
  • Hi Alvin,

    Thank you for your follow up.  My apologies for the lack of response.  I've been away from work for the Thanksgiving holiday.

    I have played with the cipher suite order on our 2008 R2 machines without any success.  If I move 3DES to the bottom of the list, it is still used when the FIPS setting is enabled.  If I completely remove 3DES from the list and keep FIPS enabled, RDP breaks.

    Tuesday, November 29, 2016 5:19 PM
  • We are seeing the same thing.  Disabling 3DES breaks RDP!

    Bruno Frisan

    Tuesday, November 29, 2016 9:58 PM
  • Hi,

    I am sorry that this issue still hasn't been resolved.

    If there is no progress, I would suggest you contact Microsoft Customer Services and Support to get an efficient solution:

    http://support.microsoft.com/contactus/?ln=en-au

    Have a nice day.

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, November 30, 2016 5:20 AM
    Moderator
  • This is the fix for this vulnerability

    1-     Create a new Key in the registry

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168

    Create Dword and set the value to 0

    2-       Browse to Computer\windows settings\Security settings\local policies\security options.

    System Cryptography: Use FIPS Algorithms - select Enabled 

    it this solution worked on windows server 2012 r2 and not 2008 r2 , i am trying to find out why the same resolution is not applied on windows 2008


    • Edited by taz jack Wednesday, November 30, 2016 10:04 PM
    Wednesday, November 30, 2016 8:46 PM
  • 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

    • Proposed as answer by K010S Thursday, December 8, 2016 8:50 PM
    Thursday, December 8, 2016 8:50 PM
  • That's great news!  I'll try it out.  I won't be able to verify immediately because the Security Center server that we use for vulnerability scans is being updated and is down at the moment, but I'll confirm your answer as soon as I can.  Thank you for your input!
    Thursday, December 8, 2016 11:58 PM
  • Hi,

    Thanks for your kindly sharing.

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, December 9, 2016 6:21 AM
    Moderator
  • Is this still working for you?  I tried this and I thought it was working because I could remote desktop. I went back in to check to make sure it was still set, and it was not set.  So I set it to take off 3DES again and rebooted again, then I could not remote desktop.

    Any other tips?

    I have the 168/168 in registry.

    Monday, December 12, 2016 9:23 PM
  • here is the solution i found

     

    1-      Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security\set client connection encryption level ( high )

    2-       Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options\ System Cryptography: Use FIPS Compliant Algorithms For Encryption enabled

     

     

    1-     Create a new Key in the registry

     

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168

     

    Create Dword and set the value to 0

     

          2-

     

    Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security\require use of specific security layer for remote (rdp) connections enable and set value to RDP


    • Edited by taz jack Wednesday, December 14, 2016 8:23 PM
    Wednesday, December 14, 2016 8:22 PM
  • I just tried and could get in so I tried on another machine - windows 8 fails.  Windows 7 works fine with RDP on the 2008 box but Windows 8 fails.  Looking at the log it looks like there is no cipher suite that works between them.  So weird.  I am still working on it.  

    Thanks,

    Wednesday, December 14, 2016 9:28 PM
  • 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.

    • Proposed as answer by Ian.Fuller Tuesday, January 10, 2017 10:25 PM
    • Marked as answer by r.mangan Tuesday, January 10, 2017 11:32 PM
    Tuesday, January 10, 2017 10:25 PM
  • We are using Nessus and for some reason the 168/168 did cause it to drop off but it came back, and only on the 2008s this time (scanned 10 days ago).  Thank you very much for the great detail in your response Ian.Fuller.  I have no idea why the 168/168 caused it to go away and then have it show back up.  I am going to have to take this on to management and see what they want as well as chat with Tenable support on why/how it came back/went away.


    Thursday, February 9, 2017 10:26 PM
  • I've seen the same thing here. I'll go into the registry, delete and re-add the cipher orders, then into GPEdit and do the same thing. Reboot and Nessus is happy. 2 hours later, they're all flagging again. Weird thing, I have 3 servers, all 2008R2, 2 of them are flagging and 1 isn't. I've copied over registry entries and combed over GP settings to no avail. They only thing I can see the 2 servers having in common, which the 3rd doesn't, is the server's SSL certificate is SHA-1. I'm going to request a new certificate today. 
    Friday, February 10, 2017 1:25 PM
  • It turns out Microsoft is not even recommending enabling FIPS unless you have to. 

    https://blogs.technet.microsoft.com/secguide/2014/04/07/why-were-not-recommending-fips-mode-anymore/

    Criteria for "have to" means either you are a government agency subject to FIPS, or you are doing testing for working with that class of computers. Otherwise, enablingFIPS is actually less secure than disabling it, because there are better algorithms which have not yet been FIPS-certified.

    Friday, February 10, 2017 9:35 PM
  • You need to enable all 4 Settings to get your system back

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128]
    "Enabled"=dword:00000000
     
    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
    "Enabled"=dword:00000000
     
    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
    "Enabled"=dword:00000000

     HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168

    "Enabled" = 0

    Also check which port Sweet32 is coming application or RDP

    Wednesday, February 22, 2017 8:57 AM
  • Hi,

    I used BeyondTrust,

    Triple DES 168/168 syntax is wrong, it stills shown vulnerability after disabled.

    The correct syntax is Triple DES 168\enabled=0

    Alan

    Thursday, October 5, 2017 9:14 PM
  • Op,

    For Windows 2008 R2 

    Thursday, October 5, 2017 9:15 PM
  • Hi Ian,

    Kindly confirm if as per the entire discussion below is the right settings:

    Server 2008:

     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168

    Server 2008 R2, 2012, 2012 R2, 2016:

     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168

    Monday, December 18, 2017 3:10 PM
  • pareekp, I don't have a 2008 server to confirm (use the information on my post to confirm for yourself) but I believe the setting is the same for all the OS variants, "Triple DES 168". At any rate, it will not harm your system to put both keys.
    Monday, December 18, 2017 4:51 PM