Forcing RDP to use TLS Encryption

Article

Aug 26, 2019

0 min read

Select Language

English

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!

Your systems should work, and your network should be protected with the strongest security possible. With Dispel, protect your network with Moving Target Defense.

Get your demo at https://dispel.io

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

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!

Your systems should work, and your network should be protected with the strongest security possible. With Dispel, protect your network with Moving Target Defense.

Get your demo at https://dispel.io

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

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!

Your systems should work, and your network should be protected with the strongest security possible. With Dispel, protect your network with Moving Target Defense.

Get your demo at https://dispel.io

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

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!

Your systems should work, and your network should be protected with the strongest security possible. With Dispel, protect your network with Moving Target Defense.

Get your demo at https://dispel.io

From the Editor

Dispel Products Remain Operational During Global Outage

Article

Jul 19, 2024

Dispel Products Remain Operational During Global Outage

Article

Jul 19, 2024

Dispel Products Remain Operational During Global Outage

Article

Jul 19, 2024

Unmanned Vehicle Operations with Zero Trust Security

Article

Jul 18, 2024

Unmanned Vehicle Operations with Zero Trust Security

Article

Jul 18, 2024

Unmanned Vehicle Operations with Zero Trust Security

Article

Jul 18, 2024

Dispel Zero Trust Access Wins Best of Show at Interop Tokyo 2024

Press Release

Jun 17, 2024

Dispel Zero Trust Access Wins Best of Show at Interop Tokyo 2024

Press Release

Jun 17, 2024

Dispel Zero Trust Access Wins Best of Show at Interop Tokyo 2024

Press Release

Jun 17, 2024

We're raising the standard for factory optimization

See what makes Dispel better

Book a demo

Access Windows

Create Access Window

Access Windows (8)

Archived On

Requested on

Stephen Maturin

Approved

7/19/14

6/19/14

Jack Aubrey

Approved

7/19/14

6/19/14

2798

Savannah Nguyen

Approved

7/19/14

6/19/14

2798

Jacob Jones

Approved

7/19/14

6/19/14

2798

Kathryn Murphy

Rejected

7/19/14

6/19/14

2798

Albert Flores

Approved

7/19/14

6/19/14

2798

Jane Cooper

Approved

7/19/14

6/19/14

We're raising the standard for factory optimization

Discover the power of Dispel with a personalized demo and a free 30-day trial

Book a demo

Access Windows

Create Access Window

Access Windows (8)

Stephen Maturin

Approved

6/19/14

Jack Aubrey

Approved

6/19/14

2798

Savannah Nguyen

Approved

7/19/14

6/19/14

2798

Jacob Jones

Approved

7/19/14

6/19/14

2798

Kathryn Murphy

Rejected

7/19/14

6/19/14

2798

Albert Flores

Approved

7/19/14

6/19/14

2798

Jane Cooper

Approved

7/19/14

6/19/14

We're raising the standard for factory optimization

Discover the power of Dispel with a personalized demo and a free 30-day trial

Book a demo

Access Windows

Create Access Window

Access Windows (8)

Archived On

Requested on

Stephen Maturin

Approved

7/19/14

6/19/14

Jack Aubrey

Approved

7/19/14

6/19/14

Savannah Nguyen

Approved

7/19/14

6/19/14

2798

Jacob Jones

Approved

7/19/14

6/19/14

2798

Kathryn Murphy

Rejected

7/19/14

6/19/14

2798

Albert Flores

Approved

7/19/14

6/19/14

2798

Jane Cooper

Approved

7/19/14

6/19/14

Checking...

61 Greenpoint Ave, Brooklyn, NY 11222

Legal Center

Privacy

Acceptable Use

Checking...

61 Greenpoint Ave, Brooklyn, NY 11222

Legal Center

Privacy

Acceptable Use