“Man In The Middle (MITM) attack” is a term used to describe a class of security vulnerabilities in which an attacker intercepts communication between two parties and impersonates each one to the other. The attacker can view and/or modify the traffic without the two parties knowledge. As a result, a user might be tricked into entering his credentials on a spoofed server. Even though RDP traffic between the client and server is encrypted, the attacker can potentially bypass RDP encryption if he is able to get the keys used to establish the session. Thus, server authentication is necessary to prevent MITM attacks.
Significant improvements in authentication and security have been made in Terminal Services that can protect against such attacks. Terminal servers running Windows 2003 Server SP1 and later support the ability for a TS client to authenticate a TS server, which protects against MITM attacks. In Windows 2003 Server SP1 and later, you can configure the TS server with a SSL/TLS server certificate that will allow the client to verify the server’s identity. In Windows Server 2008, Network Level Authentication (NLA) is designed to be secure against MITM, and it supports the ability to authenticate the server with either a SSL/TLS server certificate or Kerberos.
Terminal servers running Windows 2003 Server without SP1 or earlier do not support a clients’ ability to authenticate the terminal server. With these earlier versions, you must ensure that your network is tamper-proof by using network level protection mechanisms (for example, IPSec) in order to protect against MITM attacks.
Server authentication mechanisms that can protect against MITM attacks
1. Network Level Authentication (NLA): NLA uses the Credential Security Support Provider (CredSSP) Protocol to perform strong server authentication either through TLS/SSL or Kerberos mechanisms, which protect against MITM attacks. In addition to improving authentication, NLA also helps protect the remote computer from malicious users and software by completing user authentication before a full RDP connection is established; an additional benefit is that fewer resources are used on the remote computer prior to authentication. Please see this MSDN article or the protocol specification for more details on the CredSSP protocol.
NLA with Kerberos
This is one of the most secure server authentication schemes for protecting against MITM. Both client and server should be a part of the same or a trusted domain.
NLA with TLS/SSL
There are scenarios in which Kerberos cannot be used for server authentication, which include:
o Terminal server farms, because farms do not have a Kerberos identity in Active Directory
o Internet connection scenarios (for example through TS Gateway), in which the client does not have access to Key Distribution Center (KDC)
o The terminal server is not domain-joined
In such scenarios where Kerberos cannot be used for server authentication, deploying SSL/TLS certificates that are issued by a trusted Certificate Authority will enable the client to identify the server’s identity and protect against MITM attacks. You will need to deploy these certificates to each TS server on which you want to have server authentication and ensure that they have the server name in the Subject field. To set the SSL certificate for a connection on Windows Server 2008:
1. At a command prompt, run tsconfig.msc. (Note: tsconfig.msc is only available on Server SKUs.)
2. Double-click the RDP-TCP connection object.
3. On the General tab, click Select.
4. Select the certificate you want to assign to the connection, and then click OK.
5. Please see this TechNet article on configuring trusted rdp publishers on the client side via Group Policy.
NLA with NTLM
If SSL/TLS certificates are not configured on the server and Kerberos authentication is not possible due to the reasons stated above, CredSSP will use the NTLM authentication mechanism to establish trust between the client and server. NTLM can verify a target server’s domain membership; however, if you would like to ensure strong server authentication, you must disable allowing credential delegation with NTLM-only server authentication. To disable these policies on Windows Server 2008, follow these steps:
a. At a command prompt, run gpedit.msc to open the Group Policy Object Editor.
b. Navigate to Computer Configuration -> Administrative Templates -> System -> Credentials Delegation.
c. Ensure the following policies for NTLM-only server authentication are disabled:
i. “Allow Default Credentials with NTLM-only Server Authentication”
ii. “Allow Fresh Credentials with NTLM-only Server Authentication”
iii. “Allow Saved Credentials with NTLM-only Server Authentication”
2. Pure SSL/TLS is a standard mechanism that enables clients to authenticate to servers and provides a secure channel by encrypting communications. To use SSL/TLS, you must obtain certificates issued by a trusted Certificate Authority and configure them on each terminal server on which you want to have server authentication.
a. See steps above for setting SSL certificates on Windows Server 2008.
b. See this Knowledge Base article for information on how to configure Windows Server 2003 SP1 to use TLS for server authentication.
3. Network Level Protection mechanisms can be used to mitigate MITM attacks when the server OS version does not support NLA or pure SSL/TLS server authentication mechanisms. For example, you can configure IPSec policies on these earlier versions of TS in order to get mutual authentication and protect RDP traffic against MITM attacks.
a. See this KB article for information on configuring IPSec for TS communications in Windows Server 2003.
b. See this KB article for information on configuring IPSec for TS communications in Windows Server 2000.
4. A virtual private network (VPN) tunnel can be set up to secure your connection and prevent MITM attacks when users are connecting to servers on your network via the Internet. See this step-by-step guide on configuring Remote Access Server on Windows Server 2003.
Mitigation mechanisms supported on different Server OS versions
The table below provides a summary of mitigation mechanisms available for various server OS versions and corresponding clients.
Server OS Version
*Windows XP Service Pack 3 now supports NLA; therefore if you have Windows Server 2008 in your environment, it is strongly recommended that you upgrade to Windows XP SP3 or later in order to take advantage of Network Level Authentication. See this Knowledge Base article for more details on upgrading to TS Client 6.1 with Windows XP SP3.
· Note that CredSSP is not enabled on Windows XP SP3 by default; therefore you will also need to perform the steps outlined in this KB article to turn on CredSSP.
· Also note that even though RDP Client 6.1 is available on Windows XP SP2 now, NLA is still not supported on Windows XP SP2.
Windows Server 2003 SP1 and higher
Strong server authentication, which prevents MITM attacks can be achieved on Windows Server 2003 SP1 and higher, using the two server authentication mechanisms described above. Pure SSL/TLS can be used for Windows Server 2003 SP1 and Windows Server 2008. In addition, Windows Server 2008 uses NLA for clients that support it.
Earlier Server OS versions prior to Windows Server 2003 SP1
As shown in the table above, TLS/SSL certificates can only be deployed on Windows Server 2003 SP1 and later, while NLA is available only on Windows Server 2008. Windows Server 2003 without SP1 and earlier does not support NLA or pure SSL/TLS server authentication mechanisms. Therefore, on earlier Server versions, you will need to use network level protection mechanisms (such as IPSec) to get mutual authentication and protect RDP traffic against MITM attacks. Alternatively, you can set up a VPN tunnel for your connection.
1. See this KB article for information on configuring IPSec for TS communications in Windows Server 2003.
2. See this KB article for information on configuring IPSec for TS communications in Windows Server 2000.
3. See this step-by-step guide on configuring Remote Access Server on Windows Server 2003.
Client SKU used as a TS server
If you are connecting remotely to client operating systems, then only Windows Vista and Windows Vista SP1 that support Network Level Authentication will be able to provide strong server authentication with Kerberos as Windows Server 2008 described above. NLA with SSL/TLS is not possible on Client SKUs. On a downlevel client OS, you can configure VPN to secure your communications. See this KB article on configuring VPN on Windows XP.
PingBack from http://allstarnic.com/ssl-certificates-news/configuring-terminal-servers-for-server-authentication-to-prevent.htm
You Had Me At EHLO... : Where does the time go? -519 Jet_errLogSequenceEnd Microsoft Advanced Windows
Why create Kerberos Identity for farms? In Windows 2008, it is possible to provide server authentication
Can anyone please explain what is the difference between NLA with SSL/TLS and pure SSL/TLS?
Also, it is mentioned that NLA with SSL/TLS cannot be used on client skus as TS servers. Is it possible to use pure SSL/TLS on client skus as TS server?
NLA uses CREDSSP protocol (see http://download.microsoft.com/download/9/5/E/95EF66AF-9026-4BB0-A41D-A4F81802D92C/[MS-CSSP].pdf)
CredSSP is a complex protocol that performs TLS handshake and then either Kerberos or NTLM handshake. So, a server can be authenticated by either its SSL certificate or by Kerberos.
In som scenarios Kerberos does not work (see "NLA with TLS/SSL" section above). In these cases the only way to authenticate a server is by using its certificate. By default each server is supplied with a self-signed certificate which, obviously, not trusted by clients. So you need to replace this certificate with a trusted one.
It is possible to install a certificate on both, client and server SKU, but the OS version on the client SKU should be at least Vista. On client SKU there is no tsconfig.msc, so you'll have to use WMI to configure the certificate (see http://msdn.microsoft.com/en-us/library/aa383799(VS.85).aspx)
"Pure SSL/TLS" simply means TLS protocol used for server authentication only.
Pure SSL/TLS is supported by Win 2003 SP1 and up (both, client and server SKU), but it's not supported on XP.
You can use pure SSL/TLS to authenticate a client SKU (starting with Vista), but it has to be configured with a proper certificate.
I hope I clarified it at least a little bit :-)
"Why create Kerberos Identity for farms? In Windows 2008, it is possible to provide server authentication"
It is not possible to authenticate a Windows 2008 farm unless each server on the farm is configured with a farm certificate.
Enabling Kerberos Identity is much simpler.
After reading and searching for over 3 hours now, I think I'm on the right spot.
All I want to do is, get a secure remote desktop connection from one win7 to another win7 machine.
Using the default settings I get a security warning, that the remote server is not trusted. So far so good.
But how can I successfully install the certificate on the client computer to trust the certificate of the other win7 machine?!?
How can something be secure if such simple tasks are impossible to do? It seems everyone who has these troubles just lowers the security settings. This is the wrong way!
Please shed some light on the issue. Not from the enterprise but from the normal users point of view! Thanks.
Are both of your client machines domain joined or are they personal home machines? inside the domain you'll be able to get Kerberos auth but without that, you do have to configure certificates for server authentication over internet.
You can install the server's certificate on your client machine, so it would trust the server.
However, you have to install it into your computer account's certificate store instead of user's certificate store.
If you already have it installed in your user store, you can simply copy it over to the computer store.
I've followed the instructions to enable TLS for RDP on Vista (Enterprise) at http://articles.techrepublic.com.com/5100-10878_11-6166676.html
Essentially, this consists of setting the RDP parameters using group policies (via gpedit.msc).
Although this seems to work, I'm unable to configure an existing certificate I have for this host: it always regenerates its own self-signed certificate. I'm able to see this self-signed certificate using mmc.exe -> add Certificate snap-in, and then Certificates -> Remote Desktop -> Certificates. I've tried to delete it and to leave only the one I want to use (emitted by a CA) there, but this doesn't work.
How is it possible to select which certificate to use for the RDP server on Windows Vista? That's something I've been able to do quite easily on Windows Server (using tsconfig.msc as described in this article).
I've set up a certificate for TLS authentication on a Windows 2008 Server (and on another Vista Enterprise machine), and I've tried a few clients combinations (for which this certificate hadn't been set up), to see what they were actually checking.
In the Advanced/Connection tab (RDP client 6.1 or 7.0), I've selected "Warn me". Since the certificate is new to the clients I've tested, it should show a warning box saying something like "the remote computer could not be authenticated due to problems with its security certificate [...]", looking like this: http://blogs.msdn.com/photos/ts/images/1980609/original.aspx
I do get this box using RDP client under:
- Windows XP Pro
- Windows Vista Enterprise
However, whether I choose "warn" or "don't connect" if the server's identity can't be verified, there's absolutely no warning using the client under:
- Windows XP Home
- Windows Vista Home Premium
- OSX (RDP 2 client)
The clients running on Home editions or OSX have the same advanced options to check the certificate but do absolutely nothing when they encounter a certificate they can't possibly know (either self-signed or an unknown CA).
Is this really normal?
RDP client won't show any warning if it manages to authenticate the server via Kerberos. Maybe this is what is happening in your case?
Thanks for your reply. There's no Kerberos/ActiveDirectory/KDC involved at all in the machines I'm using.
I've managed to get a warning under XP Home edition (so perhaps it was just that particular machine); I'm unable to try again from Vista Home (machine no longer available to me).
However, I've just installed RDC on another Mac, and I can log on to a Windows Vista Enterprise box, with a self-signed certificate (as I described in my comment on 21/12), without any warning or error at all, with "Do not connect if authentication fails" ticket. Connecting to this machine from the client under XP/7 does generate a warning (asking whether I'm willing to trust this certificate).
This happens for me on two distinct Macs, which had no way of knowing about this self-signed certificate. The same behaviour happened against a Windows 2008 Server box with a certificate emitted by a CA it couldn't possibly know.
In addition, I'd like to make a couple of comments regarding the user interface of the RDC under Windows:
1. When connecting to a server with a certificate from a CA, a little lock stays in the corner, and it's possible to look at the certificate and certification path at any time (like web browsers do); when connecting to a server with a self-signed certificate, no lock and no certificate information are available once connected. This would be equally useful for self-signed certificates.
2. RDC asks for the username/password before displaying the warning dialog box about the certificate. Even if it's probably not sent without the certificate approval, it would be better to ask for the password only afterwards.
I cannot comment on Mac clients, I don't know how they are implemented.
As for Windows clients, the behavior depends on multiple factors: Using CredSSP vs. TLS, OS and RDP client versions.
Using CredSSP vs. TLS(SSL) for server authentication:
On Vista and XP SP3 CredSSP does not honor RDP client’s authentication settings. It should be configured via Credentials Delegation policy instead. For more information, please, see: http://support.microsoft.com/kb/951608. We have fixed this issue in Win 7, though, i.e. you’d get the same warnings as with TLS.
When using TLS you should get the same warnings as expected.
On Vista RDP client always uses CredSSP, unless server does not support it or “enablecredsspsupport:i:0” is set in the RDP file. On XP SP3 CredSSP needs to be enabled manually. On earlier versions of XP CredSSP is not installed, so the only option you have is TLS. On Mac, as far as I know, CredSSP is not installed either.
Now regarding your suggestions:
1. I agree, it makes sense to display the untrusted cert information. I’ll convey your suggestion to my manager.
2. Unfortunately, this is the way SSPI works. It requires user credentials before starting a handshake. I don’t think we can do anything about it.
It sounds like CredSSP is primarily intended to be used in a Domain environment with Kerberos. I'm trying to figure out whether CredSSP/NTLM is secure against MITM in this situation:
NOTE: Wherever I say NTLM, I mean NTLMv2.
Home PC runs Windows Vista and requires Network Level Authentication. No domain membership. Only allow a single account to connect via Remote Desktop, give it a long random password, and make it a non-admin. (use gpedit.msc to remove the default Administrators right to connect via TS.) Open port 3389 to the Internet.
Remote PC connects to Home PC over the Internet using RDP. The CredSSP specification states that it will perform mutual authentication, but it doesn't get into specifics. All documentation indicates that NTLM does not support mutual authentication.
The only way to do this, I think, would be to do the NTLM handshake twice, once in each direction. That would prove that both PCs know the password, which would be enough in my specific scenario. (This is only because it is a local account. In a domain environment, this would only prove that the server was in the right domain.) And then I suppose the final session key that's tied to TLS would have to be a combination of both NTLM session keys.
I suspect that it doesn't do this. Just looking for some clarification though. The only alternative would be to trust the self-signed certificate, and then connect using TLS instead of CredSSP.