Windows Remote Desktop Protocol (RDP) is widely used by system administrators trying to provide remote operators access to internal systems and servers. In a shocking oversight this connection does not use strong encryption by default.
This post will walk through the steps required to force TLS encryption on all RDP connections.
Step 1: Open the Root Console
open the search bar and type "mmc" or run mmc.exe from the Run application.
Select the top application, which will open the system console.
Step 2: Open the Group Policy Editor Snap-in
Open File > Add/Remove Snap-in... and select Global Policy Editor.
Select "Group Policy Editor" and "Add" the selected snap-in.
Select "Local Computer" - this should be the default - and select "Finish" > "Ok."
Step 3: Navigate to the RDP Session Security Policies
In the sidebar Navigate to Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Hosts > Security. Then select "Set client encryption level" and edit that policy
Step 4: Require the Highest native Encryption possible.
Edit the "Set client encryption level" policy.
Here are the notes for the different options that Microsoft Provides
If you enable this policy setting, all communications between clients and RD Session Host servers during remote connections must use the encryption method specified in this setting. By default, the encryption level is set to High. The following encryption methods are available:
High: The High setting encrypts data sent from the client to the server and from the server to the client by using strong 128-bit encryption. Use this encryption level in environments that contain only 128-bit clients (for example, clients that run Remote Desktop Connection). Clients that do not support this encryption level cannot connect to RD Session Host servers.
Client Compatible: The Client Compatible setting encrypts data sent between the client and the server at the maximum key strength supported by the client. Use this encryption level in environments that include clients that do not support 128-bit encryption.
Low: The Low setting encrypts only data sent from the client to the server by using 56-bit encryption.
An important note: This only pertains to the connections that use the native RDP encryption. As of writing this, the protocol involved for RDP traffic is RC4. That should frighten you.
Step 5: A better idea -> Force TLS instead
Edit the "Require use of specific security layer for remote (RDP) connections" policy.
Here are the notes from Microsoft on this policy:
This policy setting specifies whether to require the use of a specific security layer to secure communications between clients and RD Session Host servers during Remote Desktop Protocol (RDP) connections.
If you enable this policy setting, all communications between clients and RD Session Host servers during remote connections must use the security method specified in this setting. The following security methods are available:
Negotiate: The Negotiate method enforces the most secure method that is supported by the client. If Transport Layer Security (TLS) version 1.0 is supported, it is used to authenticate the RD Session Host server. If TLS is not supported, native Remote Desktop Protocol (RDP) encryption is used to secure communications, but the RD Session Host server is not authenticated. Native RDP encryption (as opposed to SSL encryption) is not recommended.
RDP: The RDP method uses native RDP encryption to secure communications between the client and RD Session Host server. If you select this setting, the RD Session Host server is not authenticated. Native RDP encryption (as opposed to SSL encryption) is not recommended.
SSL (TLS 1.0): The SSL method requires the use of TLS 1.0 to authenticate the RD Session Host server. If TLS is not supported, the connection fails. This is the recommended setting for this policy.
At the very least Microsoft admits that the Native RDP encryption is not recommended.
With that, you've forced TLS. In the next post, we will go over how to check that the TLS encryption you've set in this post is actually running as expected.
Hi! 👋
You've reached the end of this guide, which is one of our most popular blog posts. If you've never heard of Dispel before, we're a zero trust access platform for industrial control systems.
If you're in OT/ICS, we'd love to talk. You can book a demo right with our team here. We're as helpful as this post!