Hello, I have a question:

does RDP protocol supports TLS 1.1. I did find similar question for TLS 1.2:

http://social.technet.microsoft.com/Forums/en/winserverTS/thread/e308a2ac-2443-4a24-abc7-fab6079fac86

Hi,

 

In my experience, so far, RDP supports TLS 1.0.

 

SSL (TLS 1.0):
SSL (TLS 1.0) will be used for server authentication and for encrypting all data transferred between the server and the client.

 

A certificate is needed to authenticate an RD Session Host server when SSL (TLS 1.0) is used to secure communication between a client and an RD Session Host server during RDP connections.

 

By default, Remote Desktop connections are encrypted at the highest level of security available (128-bit). However, some older versions of the Remote Desktop Connection client application do not support this high level of encryption. If a high level of encryption is needed to support legacy clients, the encryption level of the connection can be configured to send and receive data at the highest encryption level supported by the client. There are four levels of encryption available:

· Low Data sent from the client to the server is encrypted using 56-bit encryption. Data sent from the server to the client is not encrypted.

· Client Compatible Encrypts client/server communication at the maximum key strength supported by the client. Use this level when the terminal server is running in an environment containing mixed or legacy clients. This is the default encryption level.

· High Encrypts client/server communication using 128-bit encryption. Use this level when the clients accessing the terminal server also support 128-bit encryption. When encryption is set at this level, clients that do not support this level of encryption will not be able to connect.

· FIPS Compliant All client/server communication is encrypted and decrypted with the Federal Information Processing Standards (FIPS) encryption algorithms. FIPS 140-1 (1994) and its successor, FIPS 140-2 (2001), describe U.S. government requirements for encryption.

 

More information:

Support for SSL/TLS protocols on Windows

http://blogs.msdn.com/b/kaushal/archive/2011/10/02/support-for-ssl-tls-protocols-on-windows.aspx

 

 

My question was specifically about TLS 1.1 and TLS 1.2 support by RDP, I know that tls 1.0 is supported.

No it doesn't. I posted that question having tried to configure both protocol versions without success to confirm my results (and to make sure there was not a reg entry I was missing). RDC client will not send anything higher than TLS1.0 and the server will not accept TLS.1.1 or TLS1.2 (if you send it client hellos with TLS1.2 in the header it just responds with TLS1.0). If you disable TLS1.0 and below you cannot connect. By the way if you are asking due to the recent BEAST ruckus, then be aware that the attack requires a web browser based script to inject plaintext. It's really a rehash of the decade old CBC attack but utilising subtle breaches in browser single origin SSL policy. So more PR than practical exploit (XSS attacks would probably be possible in most instances where BEAST could work). In any case not really an issue for RDP and other protocols, but it would still be nice to see a TLS1.1/1.2 Update for RDP...

• Proposed as answer by HackedOffAdmin Sunday, January 22, 2012 2:02 PM
• Edited by HackedOffAdmin Sunday, January 22, 2012 2:21 PM
• Marked as answer by Vasily K Monday, January 23, 2012 5:36 PM

No it doesn't. I posted that question having tried to configure both protocol versions without success to confirm my results (and to make sure there was not a reg entry I was missing). RDC client will not send anything higher than TLS1.0 and the server will not accept TLS.1.1 or TLS1.2 (if you send it client hellos with TLS1.2 in the header it just responds with TLS1.0). If you disable TLS1.0 and below you cannot connect. By the way if you are asking due to the recent BEAST ruckus, then be aware that the attack requires a web browser based script to inject plaintext. It's really a rehash of the decade old CBC attack but utilising subtle breaches in browser single origin SSL policy. So more PR than practical exploit (XSS attacks would probably be possible in most instances where BEAST could work). In any case not really an issue for RDP and other protocols, but it would still be nice to see a TLS1.1/1.2 Update for RDP...

• Proposed as answer by HackedOffAdmin Sunday, January 22, 2012 2:02 PM
• Edited by HackedOffAdmin Sunday, January 22, 2012 2:21 PM
• Marked as answer by Vasily K Monday, January 23, 2012 5:36 PM

I'm curious to follow up on this issue...I have a website running on 2008R2/IIS7.5 that's failing mcafee's PCI scanning service because TLS 1.0 is enabled. I disabled TLS 1.0 and inadvertently broke RD because I had "Network Level Authentication" selected.

I was able to restore connectivity by forcing Remote Desktop Session Host Config back to "RDP Security Layer" from "SSL (TLS 1.0)", but this is not ideal. I wonder how many other admins required to meet PCI will attempt to disable TLS 1.0 and get bitten this way :(

What version of TLS does Windows Server 2012 RDS support?

I'm having the same problem and I can't find a solution.  Disabling TLS 1.0 to pass the compliance tests (and avoid the BEAST exploit) kills RDP (unless you go back to the low grade security on RDP, which then disallows Network Level Authentication.)

So removing TLS 1.0 is a 'requirement' for the websites and NLA is a requirement for RDP.  But these seem to be mutually exclusive on Win2k8R2.

The key HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders   \SCHANNEL\Protocols seems to be a system setting (and not specific to IIS)

Help?

• Edited by Blake Duffey Monday, June 24, 2013 11:33 PM more info added

I'm having the same problem and I can't find a solution.  Disabling TLS 1.0 to pass the compliance tests (and avoid the BEAST exploit) kills RDP (unless you go back to the low grade security on RDP, which then disallows Network Level Authentication.)

So removing TLS 1.0 is a 'requirement' for the websites and NLA is a requirement for RDP.  But these seem to be mutually exclusive on Win2k8R2.

The key HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders   \SCHANNEL\Protocols seems to be a system setting (and not specific to IIS)

Help?

• Edited by Blake Duffey Monday, June 24, 2013 11:33 PM more info added

Yes the key is system wide. Your only option (that I am aware of) is to migrate to Windows8/Server2012 since RPD8 does support TLS1.1/1.2.

P.S. Disabling TLS1.0 on a public website will almost certainly break most clients since even browsers that do support TLS1.1 generally do not have it on by default.

Does anybody knows if this is still the same for Windows 2012 R2? The issue is that the latest PCI-DSS or NIST certification will no longer allow SSL AND TLS 1.0 as seen here for example:

In particular, NIST SP 800-52: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations (Revision 1) which prohibits the use of TLS 1.0, SSL 2.0, and SSL 3.0 to protect Federal information because of the reliance on cryptographic algorithms that are not approved.

http://www.tenable.com/blog/pci-ssc-announces-the-end-of-ssl-usage-for-the-payment-card-industry

The issue is now that we couldnt disable TLS 1.0 in the IIS but leave it enabled for RDP. This is a more a both or nothing implementation from the microsoft side as far as I see at the moment.

Windows 2012 R2 and Windows8+ support TLS1.1 and TLS1.2 for RDP but Windows7 clients will not .

Windows 2012 R2 and Windows8+ support TLS1.1 and TLS1.2 for RDP but Windows7 clients will not .

Did you have a source for that? When I disable TLS 1.0 on my Windows 8 Test PC i still couldnt connect to Windows 2012 R2... so it seamed TLS 1.1 or 1.2 isnt working for me.

I have been working on the same issue. I believe I have been able to get the Remote Desktop client of a Windows 7 or 8 workstation to connect to my test Windows 2012R2 server with only TLS v1.2 enabled. Note I am only working on Remote Desktop for administration, I don't have the RDS role installed on my test server as it is not a domain member. I also haven't tried this on 2008R2 yet.

I'd love it if someone else can reproduce and confirm my results as this seems to show that at least Windows Server 2012R2 does indeed support TLS v1.2 Remote Desktop client connections. I suspect the key factor is replacing the default self-signed certificate that Windows creates, which is SHA1, with a SHA2 certificate. This may be why Microsoft keeps saying that only TLS v1.0 is supported. My guess is that as SHA2 is not supported below TLS v1.2 when you make RDS use a SHA2 certificate it also forces TLS v1.2. (I also experimented with a HA2 certificate with an ECC/ECDSA public key and enabling the TLS_ECHDE_ECDSA cipher suites and that worked fine too.)

Here's what I did:

1. Built a stand-alone Windows 2012R2 VM, installed all available MS patches as of 7/27/15.
2. Enabled Remote Desktop with NLA. (Requires TLS connections and NTLMv2 clients)
3. Installed a certificate into the Local Machine\Personal store signed by a private CA running AD Certificate Services. The certificate has a SHA256 signature algorithm/hash and an 2048-bit RSA public key. I copied all the other settings from the default self-signed Remote Desktop certificate. (Subject, Key Usage, Enhanced Key Usage)
4. Configure RDS to use the new certificate rather than the self-signed one. (Instructions at http://blogs.technet.com/b/askperf/archive/2014/05/28/listener-certificate-configurations-in-windows-server-2012-2012-r2.aspx)
5. Disabled all TLS protocols except TLS v1.2
6. Disabled all ciphers except AES 256
7. Disabled all hashes except SHA 256
8. Disabled all Cipher Suites except TLS_RSA_WITH_AES_128_GCM_SHA256
9. Ran gpedit.msc and forced TLS-only mode in RDC via the "Require use of specific security layer for remote (RDP) connections" setting under "Computer Configuration\Administrative Templates\Windows\Components\Remote Desktop Services\Remote Desktop Session Host\Security" so I was sure it was not negotiating down to RDP mode.
10. Hacked the 2008R2 TS management components onto the server so I could easily check the configuration. (Instructions at http://serverfault.com/questions/469980/using-tsconfig-tsadmin-in-windows-server-2012-locally)
11. Enabled "High" encryption level in RDP-TCP properties. (Don't enable the "FIPS compliant" as this is only FIPS140-1 and does not support SHA2 or TLS v1.2! Microsoft really need to get FIPS 140-2 in there, it's only been a standard since 2001!)
12. Rebooted
13. Ensure NTLMv2-only mode is configured on the RDC client workstations either in their local security policy or via GP ("Send NTLMv2 responses only" in Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options)

After all this I can connect fine from Windows 7 and 8 workstations and as far as I can tell no TLS v1.0 is being used at all.

Screenshot URL, left side shows the RDC client on Windows 8.1, right side shows the test Windows 2012 Server VM with IISCrypto (Useful free tool for cipher suite editing from Nartac Software) displaying cipher suite settings and RDP-TCP config: http://anony.ws/image/DG5c

• Edited by Aunty Dan Tuesday, July 28, 2015 12:14 AM
• Proposed as answer by SGSit 11 hours 1 minutes ago

I have been working on the same issue. I believe I have been able to get the Remote Desktop client of a Windows 7 or 8 workstation to connect to my test Windows 2012R2 server with only TLS v1.2 enabled. Note I am only working on Remote Desktop for administration, I don't have the RDS role installed on my test server as it is not a domain member. I also haven't tried this on 2008R2 yet.

I'd love it if someone else can reproduce and confirm my results as this seems to show that at least Windows Server 2012R2 does indeed support TLS v1.2 Remote Desktop client connections. I suspect the key factor is replacing the default self-signed certificate that Windows creates, which is SHA1, with a SHA2 certificate. This may be why Microsoft keeps saying that only TLS v1.0 is supported. My guess is that as SHA2 is not supported below TLS v1.2 when you make RDS use a SHA2 certificate it also forces TLS v1.2. (I also experimented with a HA2 certificate with an ECC/ECDSA public key and enabling the TLS_ECHDE_ECDSA cipher suites and that worked fine too.)

Here's what I did:

1. Built a stand-alone Windows 2012R2 VM, installed all available MS patches as of 7/27/15.
2. Enabled Remote Desktop with NLA. (Requires TLS connections and NTLMv2 clients)
3. Installed a certificate into the Local Machine\Personal store signed by a private CA running AD Certificate Services. The certificate has a SHA256 signature algorithm/hash and an 2048-bit RSA public key. I copied all the other settings from the default self-signed Remote Desktop certificate. (Subject, Key Usage, Enhanced Key Usage)
4. Configure RDS to use the new certificate rather than the self-signed one. (Instructions at http://blogs.technet.com/b/askperf/archive/2014/05/28/listener-certificate-configurations-in-windows-server-2012-2012-r2.aspx)
5. Disabled all TLS protocols except TLS v1.2
6. Disabled all ciphers except AES 256
7. Disabled all hashes except SHA 256
8. Disabled all Cipher Suites except TLS_RSA_WITH_AES_128_GCM_SHA256
9. Ran gpedit.msc and forced TLS-only mode in RDC via the "Require use of specific security layer for remote (RDP) connections" setting under "Computer Configuration\Administrative Templates\Windows\Components\Remote Desktop Services\Remote Desktop Session Host\Security" so I was sure it was not negotiating down to RDP mode.
10. Hacked the 2008R2 TS management components onto the server so I could easily check the configuration. (Instructions at http://serverfault.com/questions/469980/using-tsconfig-tsadmin-in-windows-server-2012-locally)
11. Enabled "High" encryption level in RDP-TCP properties. (Don't enable the "FIPS compliant" as this is only FIPS140-1 and does not support SHA2 or TLS v1.2! Microsoft really need to get FIPS 140-2 in there, it's only been a standard since 2001!)
12. Rebooted
13. Ensure NTLMv2-only mode is configured on the RDC client workstations either in their local security policy or via GP ("Send NTLMv2 responses only" in Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options)

After all this I can connect fine from Windows 7 and 8 workstations and as far as I can tell no TLS v1.0 is being used at all.

Screenshot URL, left side shows the RDC client on Windows 8.1, right side shows the test Windows 2012 Server VM with IISCrypto (Useful free tool for cipher suite editing from Nartac Software) displaying cipher suite settings and RDP-TCP config: http://anony.ws/image/DG5c

• Edited by Aunty Dan Tuesday, July 28, 2015 12:14 AM
• Proposed as answer by SGSit Tuesday, July 28, 2015 7:59 PM

I have been working on the same issue. I believe I have been able to get the Remote Desktop client of a Windows 7 or 8 workstation to connect to my test Windows 2012R2 server with only TLS v1.2 enabled. Note I am only working on Remote Desktop for administration, I don't have the RDS role installed on my test server as it is not a domain member. I also haven't tried this on 2008R2 yet.

I'd love it if someone else can reproduce and confirm my results as this seems to show that at least Windows Server 2012R2 does indeed support TLS v1.2 Remote Desktop client connections. I suspect the key factor is replacing the default self-signed certificate that Windows creates, which is SHA1, with a SHA2 certificate. This may be why Microsoft keeps saying that only TLS v1.0 is supported. My guess is that as SHA2 is not supported below TLS v1.2 when you make RDS use a SHA2 certificate it also forces TLS v1.2. (I also experimented with a HA2 certificate with an ECC/ECDSA public key and enabling the TLS_ECHDE_ECDSA cipher suites and that worked fine too.)

Here's what I did:

1. Built a stand-alone Windows 2012R2 VM, installed all available MS patches as of 7/27/15.
2. Enabled Remote Desktop with NLA. (Requires TLS connections and NTLMv2 clients)
3. Installed a certificate into the Local Machine\Personal store signed by a private CA running AD Certificate Services. The certificate has a SHA256 signature algorithm/hash and an 2048-bit RSA public key. I copied all the other settings from the default self-signed Remote Desktop certificate. (Subject, Key Usage, Enhanced Key Usage)
4. Configure RDS to use the new certificate rather than the self-signed one. (Instructions at http://blogs.technet.com/b/askperf/archive/2014/05/28/listener-certificate-configurations-in-windows-server-2012-2012-r2.aspx)
5. Disabled all TLS protocols except TLS v1.2
6. Disabled all ciphers except AES 256
7. Disabled all hashes except SHA 256
8. Disabled all Cipher Suites except TLS_RSA_WITH_AES_128_GCM_SHA256
9. Ran gpedit.msc and forced TLS-only mode in RDC via the "Require use of specific security layer for remote (RDP) connections" setting under "Computer Configuration\Administrative Templates\Windows\Components\Remote Desktop Services\Remote Desktop Session Host\Security" so I was sure it was not negotiating down to RDP mode.
10. Hacked the 2008R2 TS management components onto the server so I could easily check the configuration. (Instructions at http://serverfault.com/questions/469980/using-tsconfig-tsadmin-in-windows-server-2012-locally)
11. Enabled "High" encryption level in RDP-TCP properties. (Don't enable the "FIPS compliant" as this is only FIPS140-1 and does not support SHA2 or TLS v1.2! Microsoft really need to get FIPS 140-2 in there, it's only been a standard since 2001!)
12. Rebooted
13. Ensure NTLMv2-only mode is configured on the RDC client workstations either in their local security policy or via GP ("Send NTLMv2 responses only" in Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options)

After all this I can connect fine from Windows 7 and 8 workstations and as far as I can tell no TLS v1.0 is being used at all.

Screenshot URL, left side shows the RDC client on Windows 8.1, right side shows the test Windows 2012 Server VM with IISCrypto (Useful free tool for cipher suite editing from Nartac Software) displaying cipher suite settings and RDP-TCP config: http://anony.ws/image/DG5c

• Edited by Aunty Dan Tuesday, July 28, 2015 12:14 AM
• Proposed as answer by SGSit Tuesday, July 28, 2015 7:59 PM

I have been working on the same issue. I believe I have been able to get the Remote Desktop client of a Windows 7 or 8 workstation to connect to my test Windows 2012R2 server with only TLS v1.2 enabled. Note I am only working on Remote Desktop for administration, I don't have the RDS role installed on my test server as it is not a domain member. I also haven't tried this on 2008R2 yet.

I'd love it if someone else can reproduce and confirm my results as this seems to show that at least Windows Server 2012R2 does indeed support TLS v1.2 Remote Desktop client connections. I suspect the key factor is replacing the default self-signed certificate that Windows creates, which is SHA1, with a SHA2 certificate. This may be why Microsoft keeps saying that only TLS v1.0 is supported. My guess is that as SHA2 is not supported below TLS v1.2 when you make RDS use a SHA2 certificate it also forces TLS v1.2. (I also experimented with a SHA2 certificate with an ECC/ECDSA public key and enabling the TLS_ECHDE_ECDSA cipher suites and that worked fine too.)

Here's what I did:

1. Built a stand-alone Windows 2012R2 VM, installed all available MS patches as of 7/27/15.
2. Enabled Remote Desktop with NLA. (Requires TLS connections and NTLMv2 clients)
3. Installed a certificate into the Local Machine\Personal store signed by a private CA running AD Certificate Services. The certificate has a SHA256 signature algorithm/hash and an 2048-bit RSA public key. I copied all the other settings from the default self-signed Remote Desktop certificate. (Subject, Key Usage, Enhanced Key Usage)
4. Configure RDS to use the new certificate rather than the self-signed one. (Instructions at http://blogs.technet.com/b/askperf/archive/2014/05/28/listener-certificate-configurations-in-windows-server-2012-2012-r2.aspx)
5. Disabled all TLS protocols except TLS v1.2
6. Disabled all ciphers except AES 256
7. Disabled all hashes except SHA 256
8. Disabled all Cipher Suites except TLS_RSA_WITH_AES_128_GCM_SHA256
9. Ran gpedit.msc and forced TLS-only mode in RDC via the "Require use of specific security layer for remote (RDP) connections" setting under "Computer Configuration\Administrative Templates\Windows\Components\Remote Desktop Services\Remote Desktop Session Host\Security" so I was sure it was not negotiating down to RDP mode.
10. Hacked the 2008R2 TS management components onto the server so I could easily check the configuration. (Instructions at http://serverfault.com/questions/469980/using-tsconfig-tsadmin-in-windows-server-2012-locally)
11. Enabled "High" encryption level in RDP-TCP properties. (Don't enable the "FIPS compliant" as this is only FIPS140-1 and does not support SHA2 or TLS v1.2! Microsoft really need to get FIPS 140-2 in there, it's only been a standard since 2001!)
12. Rebooted
13. Ensure NTLMv2-only mode is configured on the RDC client workstations either in their local security policy or via GP ("Send NTLMv2 responses only" in Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options)

After all this I can connect fine from Windows 7 and 8 workstations and as far as I can tell no TLS v1.0 is being used at all.

Screenshot URL, left side shows the RDC client on Windows 8.1, right side shows the test Windows 2012 Server VM with IISCrypto (Useful free tool for cipher suite editing from Nartac Software) displaying cipher suite settings and RDP-TCP config: http://anony.ws/image/DG5c

• Proposed as answer by SGSit Tuesday, July 28, 2015 7:59 PM
• Edited by Aunty Dan Wednesday, August 05, 2015 12:06 AM

Aunty Dan

This works for me - you're a genius!

Tested on 2012R2 joined to a domain with no RDS role.

Used a Comodo PositiveSSL ECDSA cert and the only cipher suite I have enabled is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256

Despite IISCrypto's warning about RDP not functioning without TLS1.0, it worked.

There are plenty of stackexchange brownie-points to be had as it looks like you're the first to get this working.

• Edited by SGSit 10 hours 41 minutes ago

Aunty Dan

This works for me - you're a genius!

Tested on 2012R2 joined to a domain with no RDS role.

Used a Comodo PositiveSSL ECDSA cert and the only cipher suite I have enabled is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256

Despite IISCrypto's warning about RDP not functioning without TLS1.0, it worked.

There are plenty of stackexchange brownie-points to be had as it looks like you're the first to get this working.

• Edited by SGSit Tuesday, July 28, 2015 8:18 PM

Aunty Dan

This works for me - you're a genius!

Tested on 2012R2 joined to a domain with no RDS role.

Used a Comodo PositiveSSL ECDSA cert and the only cipher suite I have enabled is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256

Despite IISCrypto's warning about RDP not functioning without TLS1.0, it worked.

There are plenty of stackexchange brownie-points to be had as it looks like you're the first to get this working.

• Edited by SGSit Tuesday, July 28, 2015 8:18 PM

You are welcome SGSit! Can you please confirm what kind of Windows clients you are connecting with? I have had no problems with fully-patched Windows 7 and 8.1 but vanilla RTM un-patched Windows 8 and 8.1 clients seem to be unable to connect. (I am currently testing this by taking an 8.1 client from RTM to fully patched to see if this resolves it. I'm guessing possibly KB2919355 or KB3042058.)

It would be great if someone from Microsoft could officially document that this is a supported configuration, confirm what exactly has changed to allow this to work and assure us this won't get "fixed" in some future patch as all their documentation still says TLS v1.0 is needed for Remote Desktop Client connections.

As I indicated above the only requirement is you are using Windows Server 2012 R2 or Windows8 (or 8.1) as the RDP server (and as you say you don't have FIPS mode enabled). The updated RDP8 stack just appears to support TLS1.1 and TLS1.2. You also need the update on the client otherwise Windows7 clients refuse to connect with anything higher than TLS1.0. You don't have to disable everything (unless that was your objective) nor do you need an SHA2 cert (though it is strongly ill advised to continue to use SHA1 for new certs) just change your cipher suit order, both my clients and server still have TLS1.0, TLS1.1 and TLS1.2 enabled but preferentially connect via TLS1.2 (You MAY need to enable it by default on Win7 systems - see below)

[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
"Enabled"=dword:FFFFFFFF

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:FFFFFFFF

[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
"Enabled"=dword:FFFFFFFF

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:FFFFFFFF

• Edited by HackedOffAdmin 15 minutes ago

As I indicated above the only requirement is you are using Windows Server 2012 R2 or Windows8 (or 8.1) as the RDP server (and as you say you don't have FIPS mode enabled). The updated RDP8 stack just appears to support TLS1.1 and TLS1.2. You also need the update on the client otherwise Windows7 clients refuse to connect with anything higher than TLS1.0. You don't have to disable everything (unless that was your objective) nor do you need an SHA2 cert (though it is strongly ill advised to continue to use SHA1 for new certs) just change your cipher suit order, both my clients and server still have TLS1.0, TLS1.1 and TLS1.2 enabled but preferentially connect via TLS1.2 (You MAY need to enable it by default on Win7 systems - see below)

[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
"Enabled"=dword:FFFFFFFF

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:FFFFFFFF

[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
"Enabled"=dword:FFFFFFFF

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:FFFFFFFF

• Edited by HackedOffAdmin Wednesday, July 29, 2015 6:44 AM

As I indicated above the only requirement is you are using Windows Server 2012 R2 or Windows8 (or 8.1) as the RDP server (and as you say you don't have FIPS mode enabled). The updated RDP8 stack just appears to support TLS1.1 and TLS1.2. You also need the update on the client otherwise Windows7 clients refuse to connect with anything higher than TLS1.0. You don't have to disable everything (unless that was your objective) nor do you need an SHA2 cert (though it is strongly ill advised to continue to use SHA1 for new certs) just change your cipher suit order, both my clients and server still have TLS1.0, TLS1.1 and TLS1.2 enabled but preferentially connect via TLS1.2 (You MAY need to enable it by default on Win7 systems - see below)

[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
"Enabled"=dword:FFFFFFFF

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:FFFFFFFF

[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
"Enabled"=dword:FFFFFFFF

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:FFFFFFFF

• Edited by HackedOffAdmin Wednesday, July 29, 2015 6:44 AM

HackedOffAdmin,

Firstly yes, it believe you are correct that it is the updated RDP 8.x components that enable TLS v1.1 and 1.2 to work for RDS rather than having a SHA2 certificate. On my test server 2012R2 I re-instated the self-signed SHA1 certificate, the SHA1 hash and a SHA1 cipher suite, left TLS 1.0 disabled and was still able to connect. If having the RDP8 stack is what that makes this work can a Windows 2008R2 server with the KB2592687 RDP 8.0 patch can be configured the same way to use only TLS v1.2? Also have you ever found any Microsoft documentation that confirms that TLS v1.1/1.2 support was added to RDP 8.x as a feature? (Nothing in the KB2592687 article mentions it.) And why do Microsoft's own support staff continue to state only TLS 1.0 will work with RDS despite v8.0 coming out in 2012? (EG This post)

Secondly I should have pointed out that the primary objective of my project was to disable TLS v1.0 in order to pass PCI and similar security audits whilst maintaining Remote Desktop connectivity. An additional objective was to minimize the attack surface as a security best practice, therefore any unneeded cipher suite components were disabled. For example as I was using a SHA2 certificate I disabled SHA1. Everyone needs to understand what impact changing the cipher suite configuration has on other applications and services running on their servers beyond RDS (E.G. IIS, SQL Server etc.) and adjust accordingly.

Thirdly I confirmed that my test RTM Windows 8.1 client needed a minimum patch level before it could connect to the sever with my configuration (Only TLS v1.2 enabled, RDS using a SHA2/RSA certificate.) I installed only the KB3000850 November 2014 update rollup so one of the updates in that fixed it but I haven't had time to check through the 50+ patches included in it to figure out which was one was needed.

TLS_RSA_WITH_AES_128_GCM_SHA256 was not an available cipher suit in Windows8.1 RTM but was added in a TLS update that predates that rollup (event though the kb doesn't appear to list it as part of the rollup). Prior to that you only could use GCM suits with ECDSA certs (I commissioned my system with and ECDSA certificate 2 years ago for just that reason).

• Edited by HackedOffAdmin 10 hours 50 minutes ago

Ah, that makes sense. If I'd used a CBC cipher suite with my SHA256 certificate (E.G. TLS_RSA_WITH_AES_128_CBC_SHA256) it would have worked with the RTM Windows 8.1 client too.

Any idea why Microsoft haven't documented the TLS functionality of RDP v8.x?

• Edited by Aunty Dan 9 hours 54 minutes ago

TLS_RSA_WITH_AES_128_GCM_SHA256 was not an available cipher suit in Windows8.1 RTM but was added in a TLS update that predates that rollup (event though the kb doesn't appear to list it as part of the rollup). Prior to that you only could use GCM suits with ECDSA certs (I commissioned my system with and ECDSA certificate 2 years ago for just that reason).

• Edited by HackedOffAdmin Wednesday, July 29, 2015 8:10 PM

TLS_RSA_WITH_AES_128_GCM_SHA256 was not an available cipher suit in Windows8.1 RTM but was added in a TLS update that predates that rollup (event though the kb doesn't appear to list it as part of the rollup). Prior to that you only could use GCM suits with ECDSA certs (I commissioned my system with and ECDSA certificate 2 years ago for just that reason).

• Edited by HackedOffAdmin Wednesday, July 29, 2015 8:10 PM

Ah, that makes sense. If I'd used a CBC cipher suite with my SHA256 certificate (E.G. TLS_RSA_WITH_AES_128_CBC_SHA256) it would have worked with the RTM Windows 8.1 client too.

Any idea why Microsoft haven't documented the TLS functionality of RDP v8.x?

• Edited by Aunty Dan Wednesday, July 29, 2015 9:06 PM

Ah, that makes sense. If I'd used a CBC cipher suite with my SHA256 certificate (E.G. TLS_RSA_WITH_AES_128_CBC_SHA256) it would have worked with the RTM Windows 8.1 client too.

Any idea why Microsoft haven't documented the TLS functionality of RDP v8.x?

• Edited by Aunty Dan Wednesday, July 29, 2015 9:06 PM

Any idea why Microsoft haven't documented the TLS functionality of RDP v8.x?

They are pretty rubbish about this sort of thing.... :)

I think I once saw a single line bullet point in a RDP blog post about it, but it clearly hasn't disseminated to other Microsoft people on this or other sites who will normally give you the most conservative answer possible to TLS or other security questions concerning MS products.

Did somebody checked the RDP port with nMAP or similar to see if TLS 1.0 is really disabled and therefore not used on the server? I mean the IISCrypto GUI is fine, but that didnt really say that TLS 1.0 is disabled for sure... So if anybody who had tested the mentioned solution here, could quickly run a nMAP scan against the RDP port and post the result here, I would be very happy ;)

BastianWebster,

Thanks for the NMap suggestion. I ran this against my test 2012R2 server with an ECC certificate installed for RDP. It confirmed only TLS v1.2 was responding. Note that IISCrypto is just a GUI for making Registry changes. When you press "Apply" it modifies the Registry keys that manage Windows crypto suite settings. (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL and HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002) There is no effective difference between using IISCrypto and manually editing the Registry keys as per https://technet.microsoft.com/en-us/library/Dn786418.aspx. It is also possible to make changes to these settings via either the local security policy or domain GPOs but the end result is the same.

I guess it is theoretically possible for a Microsoft component to simply ignore either the Registry or policy settings and programmatically enable TLS v1.0 (or any other disabled crypto suite component for that matter) but fortunately this does not appear to be the case with the Remote Desktop Service.

This is the NMap scan output against my test 2012R2 server with only TLS v1.2 enabled:

Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-08-03 13:45 Pacific Daylight Time

Nmap scan report for 172.16.0.174

Host is up (0.00s latency).

PORT     STATE SERVICE

3389/tcp open  ms-wbt-server

| ssl-enum-ciphers:

|   TLSv1.2:

|     ciphers:

|       TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (dh 384) - A

|       TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (dh 384) - A

|     compressors:

|       NULL

|     cipher preference: server

|_  least strength: A

MAC Address: 00:50:56:86:38:F4 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 7.36 seconds

I also confirmed that unfortunately a fully-patched 2008R2 server cannot host Remote Desktop Services with TLS v1.0 disabled even though the RDP v8.x components are installed. It can however connect to other servers hosting v8.x RDP sessions with TLS v1.2 assuming suitable cipher suites are enabled. (E.G. In my test setup I had to manually enabled the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite on the 2008R2 system running the RDP client as it is not enabled by default as per https://msdn.microsoft.com/en-us/library/windows/desktop/aa374757(v=vs.85).aspx.)

An Nmap scan of my test 2008R2 server shows TLS v1.0 only enabled:

Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-08-03 12:23 Pacific Daylight Time

Nmap scan report for 172.16.0.175

Host is up (0.0030s latency).

PORT     STATE SERVICE

3389/tcp open  ms-wbt-server

| ssl-enum-ciphers:

|   TLSv1.0:

|     ciphers:

|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (dh 521) - A

|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (dh 521) - A

|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A

|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A

|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C

|     compressors:

|       NULL

|     cipher preference: server

|     warnings:

|       Weak certificate signature: SHA1

|_  least strength: C

Nmap done: 1 IP address (1 host up) scanned in 9.06 seconds

I think...I have been able to get a 2008r2 test box to run only 1.2 on 443 (but 1.0 on 3389 for RDP) by enabling "System Cryptography: Use FIPS Algorithms..." in Local Security Policy - Local Policies - Security Options. RDP was failing before I turned that on.

NMAP shows 1.2 only for port 443 and 1.0 only for 3389. 

I didn't have time to try with a full website, so I may run into an issue when I try tomorrow.

Not sure why 1.0 is working for RDP, as I turned off via IIS Crypto.

• Edited by mculbertson 1 hour 54 minutes ago

I think...I have been able to get a 2008r2 test box to run only 1.2 on 443 (but 1.0 on 3389 for RDP) by enabling "System Cryptography: Use FIPS Algorithms..." in Local Security Policy - Local Policies - Security Options. RDP was failing before I turned that on.

NMAP shows 1.2 only for port 443 and 1.0 only for 3389. 

I didn't have time to try with a full website, so I may run into an issue when I try tomorrow.

Not sure why 1.0 is working for RDP, as I turned off via IIS Crypto.

• Edited by mculbertson Tuesday, August 04, 2015 5:08 AM

Not sure why 1.0 is working for RDP, as I turned off via IIS Crypto.

Thats something I discovered as well on some systems and was the reason why I asked to check that with nMAP. At least on some of my systems IIS Crypto didnt work as expected. But a manual registry change did it, not sure why...

I just setup a new Windows 2012 R2 (fully patched) and disabled TLS 1.0 (I didnt changed the default certificate, FIPS Settings, Cipher Order, ...). From a Windows 7 (fully patched) Im still able to access the Server via RDP.

My nMAP output is:

Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-08-04 03:32 Pacific Daylight Time
Nmap scan report for xxxxxxxxxxxxxx
Host is up (0.0020s latency).
rDNS record for xxxxxxxxxxxxxxxxxxxxxxx
PORT     STATE SERVICE
3389/tcp open  ms-wbt-server
| ssl-enum-ciphers: 
|   TLSv1.1: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (dh 256) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (dh 256) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Weak certificate signature: SHA1
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (dh 256) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 128) - B
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 128) - C
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (dh 256) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (dh 256) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (dh 256) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Key exchange parameters of lower strength than certificate key
|       Weak certificate signature: SHA1
|_  least strength: C

Nmap done: 1 IP address (1 host up) scanned in 4.12 seconds

It really looks if Microsoft enabled TLS 1.1 and above for RDP, but maybe need to perform some internal quality testings before they release it to the "outer world".

It would be nice to perform an nMap against a unpdatched Windows 2012 R2 OS, to see if we do see some differences in the protocols and cipher.

• Edited by BastianWebster Tuesday, August 04, 2015 10:38 AM additional info added

Here's my NMAP output for web/rdp ports on my 2008r2 test box:

Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-08-04 10:02 Central Daylight Time
Nmap scan report for x.x.x.x
Host is up (0.00013s latency).
PORT     STATE SERVICE
3389/tcp open  ms-wbt-server
| ssl-enum-ciphers: 
|   TLSv1.0: 
|     ciphers: 
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors: 
|       NULL
|     cipher preference: indeterminate
|     cipher preference error: Too few ciphers supported
|     warnings: 
|       Weak certificate signature: SHA1
|_  least strength: C

-------------------------

Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-08-04 16:18 Central Daylight Time
Nmap scan report for xxxxxxxxxxxxxxxxxx
Host is up (0.00s latency).
rDNS record for xxxxxxxxxxxxxxxxxxxxx
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers: 
|   TLSv1.2: 
|     ciphers: 
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (dh 256) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (dh 256) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (dh 256) - A
|     compressors: 
|       NULL
|     cipher preference: server
|_  least strength: C

• Proposed as answer by Jeff Jagoda 2 hours 27 minutes ago
• Unproposed as answer by Jeff Jagoda 2 hours 27 minutes ago

This is my write up on what I did to accomplish a configured TLS 1.2 only 443 and TLS 1.0 rdp on win2k8r2 rdp server.  The fips cryptography setting above mentioned by mcluberston i think did the trick for 2008.  My Nmap are looking like mcluberston's too.

Also IIS Crypto is nice tool to use from some of the steps.

Below is my write up of what I completed to accomplish TLS 1.2 for 443 and TLS 1.0 for RDP 3389 on a Windows 2008 R2 remote desktop server.  I have test client access from windows 7, windows 2008r2 and windows 2012 r2.

Windows 2008 R2 TLS 1.2 for HTTP and RDP TLS 1.0 Configuration and nmap testing

• Installed -  KB 2574819 (may not be needed)
• (Use IIS Crypto or Reg keys, many places to find these settings)
  1. Disabled TLS protocols 1.0 and 1.1
  2. Ensure TLS v1.2 enabled
  3. Disabled all ciphers except AES 256
  4. Disabled all hashes except SHA 256
  5. Disabled all Cipher Suites except TLS_RSA_WITH_AES_128_GCM_SHA256
• Run gpedit.msc  
  1. Browse to Computer\windows settings\Security settings\local policies\security options.
     1. Network Security: LAN Manger Auth. - Choose NTLM v2 response only
     2. Network Security: Minimum Session for NTML SSP - Check NTMLv2 and 128 -
     3. Network Security: Minimum Session for NTML SSP  - Check NTMLv2 and 128 -
     4. System Cryptography: Use FIPS Algorithms - select Enabled 
  2. Browse to Computer\Adminstrative templates\Windows\Components\Remote Desktop Services\Remote Desktop Session Host\Security
     1. Require use of specific security layer for remote rdp connections Choose TLS 1.0 Only

4. Run tsconfig.msc
   1. Right Click RDP-Tcp in the connection area
   2. Change encryption level to high
   3. Click ok

5. Reboot

6. Test rdp

7. Nmap testing

NMAP Command  - nmap -p 3389 --script ssl-enum-ciphers 172.2.8.7

PORT     STATE SERVICE

3389/tcp open  ms-wbt-server

| ssl-enum-ciphers:

|   TLSv1.0:

|     ciphers:

|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C

|     compressors:

|       NULL

|     cipher preference: indeterminate

|     cipher preference error: Too few ciphers supported

 

 

NMAP Command  - nmap -p 443 --script ssl-enum-ciphers 172.2.8.7

 

PORT    STATE SERVICE

443/tcp open  https

| ssl-enum-ciphers:

|   TLSv1.2:

|     ciphers:

|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A

|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A

|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A

|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A

|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C

|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (dh 256) - A

|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (dh 256) - A

|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (dh 256) - A

|     compressors:

|       NULL

|     cipher preference: server

|     warnings:

|       Weak certificate signature: SHA1

|_  least strength: C

 

NMAP Command - nmap -p 3389 --script rdp-enum-encryption 172.2.8.7

PORT     STATE SERVICE

3389/tcp open  ms-wbt-server

| rdp-enum-encryption:

|   Security layer

|     CredSSP: SUCCESS

|_    SSL: SUCCESS

• Proposed as answer by Jeff Jagoda 1 hour 48 minutes ago
• Edited by Jeff Jagoda 1 hour 42 minutes ago