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):
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:
What could be different between the two RDP hosts that causes this issue and how to fix it?
Best Answer
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:
Reboot here if desired (and you have physical access to the machine).
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.