54

Our credit card processor recently notified us that as of June 30, 2016 we will need to disable TLS 1.0 to remain PCI compliant. I tried to be proactive by disabling TLS 1.0 on our Windows Server 2008 R2 machine, only to find that immediately after reboot I was completely unable to connect to it via Remote Desktop Protocol (RDP). After some research, it appears that RDP only supports TLS 1.0 (see here or here), or at least it's not clear how to enable RDP over TLS 1.1 or TLS 1.2. Does anybody know a way to disable TLS 1.0 on Windows Server 2008 R2 without breaking RDP? Does Microsoft plan support for RDP over TLS 1.1 or TLS 1.2?

Note: There appears to be a way to do it by configuring the server to use the RDP Security Layer but that disables Network Level Authentication, which seems like trading one evil for another.

UPDATE 1: Microsoft has now addressed this issue. See the answer below for the relevant server update.

UPDATE 2: Microsoft has released a tutorial regarding SQL Server Support for PCI DSS 3.1.

Improve this question
11
  • My apologies to everyone - the instructions that I posted are only valid for Win8/Server2012/2012R2... they don't work on 2008R2/Win7. I tested 2008R2 and it is not the same. I'm sorry.
    – Ryan Ries
    May 13, 2015 at 3:07
  • And note that on 2012 as the op mentions, removing TLS 1.0 forces RDP to downgrade to RDP security layer.
    – Jim B
    May 15, 2015 at 1:52
  • I did the same thing and can't get into my server (AWS), were you able to figure out a way to get in without physical access?
    – Thomas Paine
    May 20, 2015 at 16:35
  • 1
    According to this support article Microsoft have just recently patched SQL 2012 and 2014 to work with TLS 1.1 and 1.2 support.microsoft.com/en-us/kb/3052404
    – CarlR
    Jun 30, 2015 at 11:38
  • 1
    @CarlR that article doesn't seem to specifically mention RDP'ing to the server. In fact, it seems to be specific to database connectivity itself as it mentions: "This update adds the support for Transport Layer Security (TLS) protocol version 1.2 to SQL Server 2014 and to the Microsoft ODBC Driver for SQL Server."
    – k1DBLITZ
    Jul 8, 2015 at 20:02

9 Answers 9

Reset to default
21

Microsoft released the patch for this problem Sep 15, 2015

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

Improve this answer
5
  • Thanks very helpful. After installing this updates, tsconfig.msc screen is not showing any signs of TLS 1.1 or TLS 1.2. Does anyone was able to confirm that you are connecting to server using RDP over TLS 1.2? I know we can verify by disabling early TLS protocol on server. But if it does not work than you cannot remote using RDP to the server at all.
    – Nirlep
    Sep 18, 2015 at 17:01
  • It is possible that when you select "Negotiate" option, it will communicate highest level possible which could be TLS 1.2
    – Nirlep
    Sep 18, 2015 at 17:24
  • 1
    You can enable schannel logging to see which version is being used. The link for how to do this is shown in my answer.
    – CarlR
    Sep 19, 2015 at 17:22
  • I know it's an old thread but... I've an older Windows Server 2008 R2 I'm bringing up to snuff. I've installed KB3080079 and will now disable TLS 1.0. But I'm not sure if the RDP server setting should be set to "Negotiate" or to "TLS".
    – Chris Harrington
    Jul 6, 2017 at 13:53
  • 1
    Carl's answer below is far more helpful, and hopefully will have more votes soon.
    – Mike Williamson
    Mar 3, 2021 at 12:12
21

I have been looking into this for a couple of days now as we to have to comply with PCI-DSS 3.1 which requires TLS 1.0 to be disabled.

We also do not want to fall back to RDP Security Layer which is a major security concern.

I have finally managed to find some documentation that confirms that TLS 1.1 and TLS 1.2 ARE supported by RDP. This documentation is hidden away in an SChannel logging and a very detailed specification for RDP.

There is a complete lack of main stream documentation on Technet or other Microsoft sites it seems so hopefully documenting this here may help some people.

Relevant extracts from the links provided:

From the MSDN link:

"RDP supports four External Security Protocols: TLS 1.0 ([RFC2246]),
TLS 1.1 ([RFC4346])<39>, TLS 1.2 ([RFC5246])<40>"

From the RDP specification PDF:

"When Enhanced RDP Security is used, RDP traffic is no longer protected by using
the techniques described in section 5.3. Instead, all security operations (such as
encryption and decryption, data integrity checks, and Server Authentication) are 
implemented by one of the following External Security Protocols:
TLS 1.0 (see [RFC2246])
TLS 1.1 (see [RFC4346])
TLS 1.2 (see [RFC5246])
CredSSP (see [MS-CSSP])"

"<39> Section 5.4.5: TLS 1.1 is not supported by Windows NT, Windows 2000 Server,
Windows XP,Windows Server 2003, Windows Vista and Windows Server 2008.
<40> Section 5.4.5:  TLS 1.2 is not supported by Windows NT, Windows 2000 Server,
Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008"

Therefore one would conclude that you can use TLS 1.1 or 1.2 on Windows Server 2008 R2 according to this documentation.

However our testing has proved this DOES NOT work from the Windows 7 RDP client (version 6.3.9600) when TLS 1.0 is disabled and RDP security option is set to require TLS 1.0.

This is of course as well as enabling TLS 1.1 and 1.2 which are off by default on 2008R2 - incidentally we do this using the very useful IIS Crypto Tool from Nartac Software.

When looking at this issue it is useful to enable SChannel logging to see the more details of what is happening when your session is opened.

You can set SChannel logging by changing the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\EventLogging key to 5 and rebooting.

Once this has been done you can observe SChannel events which show the TLS version being used when an RDP connection is made. Once logging is enabled, you can observe the SChannel error when the RDP client tries to establish a connection on Windows 2008 R2 with TLS 1.0 disabled:

A fatal error occurred while creating an SSL server credential.
The internal error state is 10013.

I have also tested disabling TLS 1.0 on Windows Server 2012 and 2012 R2 which I can confirm works perfectly using the Windows 7 RDP Client. SChannel log entry shows TLS 1.2 being used:

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

   Protocol: TLS 1.2
   CipherSuite: 0xC028
   Exchange strength: 256

I hope this helps someone who is looking for clarification on this.

I will continue to look for how we might get RDP working over TLS 1.1 and TLS 1.2 in Windows Server 2008 R2.

UPDATE: 2015-AUG-05

We raised the issue of RDP not working with Server 2008 R2 with Microsoft support including steps to reproduce.

After several weeks of backwards and forwards we finally received a phone call today from the support team to acknowledge that they could indeed reproduce it and this is now categorized as a bug. An update patch will be released, at the moment this is expected this in October 2015. As soon as I have a KB article or other details I will add them to this post.

Hopefully those stuck with Windows Server 2008 R2 can at least get this resolved before the deadline of June 2016 once the patch is released.

UPDATE: 19th September 2015

Microsoft have finally released a kb support article about this here and I can confirm that it works OK.

Improve this answer
4
  • Your last update states "I've tried windows 7 and windows 2012 r2 and it doesn't work; it still connects using TLS1." Were you ever able to get this to work?
    – Doug S
    Jul 1, 2016 at 23:45
  • Someone else put that comment in, I have just removed it as it works fine for us now over TLS1.2.
    – CarlR
    Jul 4, 2016 at 8:17
  • Hmmm. I was never able to get it to work, even with these changes/updates and everything else I could find.
    – Doug S
    Jul 19, 2016 at 0:37
  • SChannel log can be found in System Log.
    – Ivan Chau
    Dec 21, 2016 at 1:53
9

Use IPsec instead, as the document recommends: "Setting up a strongly-encrypted session first (e.g. IPsec tunnel), then sending data over SSL within secure tunnel "

The main reason to do this over configuring TLS for RDP is that the firewall policy is easily audited for compliance (vs proving a buch of registry changes are compliant) and IPsec is pretty easy to configure in windows.

If you happen to need full suite B compliance IPSEC with tls 1.0 is the only way available to apply to appropriate certificate lengths

Improve this answer
5
  • Tunneling over SSH is also an option that I'll mention. (Requires SSH server software for Windows, of course.)
    – Chris W. Rea
    May 12, 2015 at 12:29
  • IPsec is not SSH
    – Jim B
    May 12, 2015 at 17:48
  • 3
    Correct, and I didn't mean to imply they are the same. Rather, SSH is an alternate method for establishing a secure tunnel to a server.
    – Chris W. Rea
    May 12, 2015 at 18:53
  • @JimB I'm sorry, you were right.
    – Ryan Ries
    May 13, 2015 at 3:07
  • 1
    @RyanRies Np, I'm still scratching my head how 12 others would vote it up without knowing it worked.
    – Jim B
    May 13, 2015 at 3:50
9

This is not an answer to the question, but to the sub-question "How do I restore remote access to a virtual machine where I've disabled TLS 1.0 and with no physical access?".

I disabled TLS 1.0 using IISCrypto, which gave a useful warning about the side effect that RDP will stop working if it is set to TLS. So I checked in:

Admin Tools\Remote Desktop Services\Remote Desktop Session Host Configuration, RDP-Tcp, General Tab, Security Layer

and my Security Level was set to "Negotiate". I assumed this means if TLS is not available, it would gracefully degrade to RDP Security.

But no, Negotiate doesn't work that way. You have to set Security Level to RDP Security, not Negociate, before you disable TLS 1.0.

So I lost my ability to remote connect to my AWS instance!

To reconnect, I used another AWS instance.

  1. I updated the SecurityGroup to allow firewall connection from that machine to my "lost" machine.
  2. I opened an administrative network share in DOS, with an admin user and password:

net use \\lost_machine_ip\c$

  1. Then I opened Regedit, and in File menu, choose "Connect Network Registry" and put in the IP of the "lost" server. You should see the remote server registry. Go to :

\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\

and set the value for SecurityLayer to 0 (0 is RDP Security).

You will then be able to remote connect, and reenable TLS 1.0 in IISCrypto if required.

Improve this answer
2
  • Thanks, this saved me a lot of work recreating a server. Not sure how you changed your security group to allow the connection between machines---I opened all access to the "lost" machine to the second machine's IP address, and that worked. Is there a better way?
    – Gullbyrd
    Jan 27, 2016 at 18:43
  • @Gullbyrd either that, or set ALL TCP to the security group that both machines belong to. Does the same thing.
    – Dave Beer
    Jan 28, 2017 at 7:44
4

You will need to install RDP 8.0 on your Windows 7 computers and Windows Server 2008 R2 servers, and then enable RDP 8.0 on the local computer policy or group policy.

Here is the Microsoft KB for the RDP 8.0. https://support.microsoft.com/en-us/kb/2592687

Once this is done you should be able to disable TLS 1.0 on the computers and servers by editing the registry as instructed in this technet article. https://technet.microsoft.com/en-us/library/dn786418.aspx

After installing RDP 8.0 you can also install RDP 8.1, but RDP 8.0 must be installed prior to installing RDP 8.1. RDP 8.0 contains both the client and server-side protocol components, but RDP 8.1 only includes the client. The Microsoft KB for RDP 8.1 is KB2830477.

I made these changes on one of my windows 7 workstations and tested the RDP connections with the "Require use of specific security layer for remote (RDP) connections" Group Policy setting enabled and set to "SSL (TLS 1.0)" to ensure that it would not fall back to RDP Encryption.

UPDATE 6/19/2015:

I finally got a chance to test this on one of our Windows Server 2008 R2 servers, and it definitely breaks RDP connections to the server. It seems that the RDP 8.0 server-side components are only installed on Windows 7 computers, and do not get installed on Windows Server 2008 R2 servers.

Improve this answer
3
  • The support knowledgebase article referenced is not working presently (redirect loop) however you can use the Google cache version to see the contents. Interesting that there is still absolutely no mention of TLS 1.1 or 1.2 support in this article and yet I guess that is the main reason anyone will be looking at this question! There are also a large number of caveats including local admins no longer being able to login unless specifically being added to Remote Destop users group. Watch out if you are trying this.
    – CarlR
    Jun 17, 2015 at 9:34
  • Did you open up UDP port 3389 on the server when you tried connecting to the 2008 server?
    – Elvar
    Jun 26, 2015 at 16:01
  • I went so far as to temporarily disable the Windows Firewall completely on the server 2008 R2 server, but I still could not connect to it using RDP with TLS 1.0 disabled on the server.
    – Kenny R
    Jun 26, 2015 at 19:34
4

As posted on How to disable TLS 1.0 without breaking RemoteApps on server 2012 R2 but reposting here for the benefit of those that may not be monitoring that link:

After almost a year, I finally figured out a working solution for disabling TLS 1.0/1.1 without breaking RDP and Remote Desktop Services connectivity and launching RemoteApps:

Run IISCrypto and disable TLS 1.0, TLS 1.1 and all bad ciphers.

On the Remote Desktop Services server running the gateway role, open the Local Security Policy and navigate to Security Options - System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing. Change the security setting to Enabled. Reboot for the changes to take effect.

Note that in some cases (especially if using self signed certificates on Server 2012 R2), the Security Policy option Network Security: LAN Manager authentication level may need to be set to Send NTLMv2 responses only.

Improve this answer
1
  • Just an update on the suggestion to enable the "FIPS Compliant" setting - there has been some debate about the pros and cons of enabling that - I recommend reading this blog post by Microsoft about it, plus the comments underneath it: blogs.technet.microsoft.com/secguide/2014/04/07/…
    – Mike
    Dec 27, 2019 at 8:11
3

Just an update on this if anyone else is looking for info on it. For my Windows 7 64-bit boxes I had to install KB2574819 (first) and KB2592687 (second) Windows 7 has to have SP1 installed before those 2 pkgs will install. If you have issues installing SP1 like I did, I had to uninstall KB958830 first, then install SP1.

For my Windows Server 2008 R2 boxes, I had to install KB3080079. Once you do this and have all the appropriate settings for secure communication put in place, then it will use TLS 1.2 You can confirm by using Wireshark to perform a capture of the communication between your two boxes.

Improve this answer
1

I've successfully used rdesktop (http://www.rdesktop.org) for Linux to work around this problem.

Improve this answer
1

One case not covered by the existing answers: Windows 7 clients connecting through an RDP Gateway will still use TLS 1.0 when connecting to the gateway and fail if the gateway does not support TLS 1.0, even after applying KB3080079, as observed in this TechNet forum thread.

To use TLS 1.2 for connecting through an RDP Gateway, ensure KB3140245 is installed and add the following registry keys (save in a file with .reg extension to import):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000800

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000800

As documented in KB3140245, this will override WINHTTP_OPTION_SECURE_PROTOCOLS to use TLS 1.2 (and only TLS 1.2) by default. So be aware it will affect more than just the RDP client.

(Note: If backwards-compatibility is desired, dword:00000800 can be changed to dword:00000A00 or dword:00000A80 to include TLS 1.1 and 1.0 respectively)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .