How do I disable TLS 1.0 without breaking RDP?

Solution 1:

Microsoft released the patch for this problem Sep 15, 2015

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

Solution 2:

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.