I was playing the other days with Windows 7 RC as a VPN client and Windows 2008 R2 RC as a VPN server, PPTP, L2TP/IPsec, SSTP and IKEv2 connections.
I found some interesting and useful improvements in the feedback provided for the simple user and the admin when attempting to connect to a VPN server and there is a misconfiguration on the validation(s) of the server’s certificate when PEAP-EAP-MSCHAPv2, PEAP-EAP-TLS or EAP-TLS are used as user authentication methods. All of them are mutual authentication protocols. If you want to use NAP for your VPN connections you need to use PEAP, see this and this.
Also now I find the configuration of a VPN connection easier than it was with Vista for example.
PEAP - uses TLS to enhance the security of the EAP authentication protocols(user passwords(like EAP-MSCHAPv2) or smart cards and certificates(like EAP-TLS )) used to authenticate the VPN user. PEAP creates an encrypted and authenticated channel to protect EAP methods running within PEAP, to put it simple: the client first establishes a SSL tunnel and validates the server’s certificate, and if everything is fine, EAP authentication takes place over this tunnel, at least from the client’s point of view(sort of), from the server’s point of view the inner EAP method should be bound to the outer PEAP to ensure the peers are the same for the outer PEAP and the inner EAP.
PEAP-EAP-TLS when used with smart cards may be the strongest user authentication method available for VPN connections on the default Windows 7 VPN client, assuming it is correctly configured and implemented. EAP-TLS itself is a pretty strong authentication method, so one may wonder what would be gained by the use of it within PEAP. Apart from eavesdroppers being not able to view some parts of the EAP-TLS authentication process, the PEAP layer, if properly implemented, may allow the client to detect an active MITM before the EAP-TLS authentication takes place. And not to forget the NAP requirement for PEAP.
Note that when you use PEAP, the protected tunnel is not established between the VPN server and the VPN client, is between the VPN client and the NPS server, so you actually validate the NPS’s identity(the PEAP server). The same is true for EAP-TLS, the identity validated by the client is the one of the NPS server(the EAP server). The NPS may be installed on the same server on which the RRAS was installed, if not, for example the NPS may be installed on a DC or on a separate machine(if so, the EAP messages sent between the VPN client and NPS server are encapsulated and formatted as RADIUS messages between the RRAS server and the NPS(RADIUS server)).
For example, for a SSTP connection, first, as part of the SSTP protocol, the client establishes a SSL connection and verifies the VPN server’s identity by examining the VPN server’s certificate, then, say the PEAP-EAP-MSCHAPv2 user authentication takes place, over the already established SSL tunnel, and if the protected tunnel provided by PEAP cannot be establish due to the client failing to validate the NPS server’s identity(assuming the client was properly configured to do so), the user’s credentials will not be sent, and the connection will be terminated. Same will be true for the IKEv2 connection in Windows 7 RC(we’re going to talk about the IKEv2 authentication enhancements in Windows 7 RC in a future blog entry), where the client first authenticates the VPN server by examining its certificate(the server uses a public key signature based authentication to authenticate itself), and after this step user authentication like PEAP-EAP-MSCHAPv2 will take place.
Due to the initial encrypted and authenticated tunnel for SSTP and IKEv2, “only” EAP-MSCHAPv2 instead of PEAP-EAP-MSCHAPv2 (if passwords are desired over certificates and you don’t need NAP) can be used for user authentication over the initial encrypted and authenticated tunnel, the user credentials being protected against dictionary attacks. There is a draft called An Extension for EAP-Only Authentication in IKEv2, which, if it passes the draft status, may allow the stronger EAP methods(obviously not EAP-MSCHAPv2 –:) ) to be used without public key signature based responder authentication with IKEv2, as these stronger EAP methods can “take care” of themselves, being used on wireless LANs and offering mutual authentication and protection against offline dictionary attacks(for passive and active MITMs).
A problem may appear for SSTP(if it’s not properly implemented, likely not the case of the RRAS –:) ), as during the initial authentication provided by SSTP, only the client has authenticated the server. Without the correct crypto binding in place, from the server’s point of view, for example when EAP-TLS is used, the user’s credentials are not “protected”-at this point the server does not know with who is talking, a legitimate VPN client or an attacker-, and EAP credentials, in some circumstances, for example from a wireless connection may be “relayed” into the VPN connection(see this for more details about the relay scenario, and this about the crypto binding). This is not an issue with IKEv2, as the keys will be derived from both the DH exchange(see sections 1.2, 2.13 and 2.14 of RFC4306) and the EAP exchange(see section 2.16 of RFC4306), and the attacker does not have the keys from the EAP exchange, so the attempt will eventually fail. The credentials from the IKEv2 or SSTP connection cannot be relayed into a wireless connection, first because of the initial validation the client does over the VPN server’s identity, and because the keys derived from the EAP exchange are not known to the attacker(the attempt will fail).
So, from EAP-TLS, PEAP-EAP-MSCHAPv2 or PEAP-EAP-TLS point of view, the identity of the NPS server should be unique, that is, for example, if the NPS server is installed on the DC or separate machine, and on the same machine a web server was also configured for HTTPS, the certificate that the NPS server uses within its policies for EAP-TLS, PEAP-EAP-MSCHAPv2 or PEAP-EAP-TLS(only the needed one from them is to be used, not all at a time) should be different than the certificate the web site uses for HTTPS. In addition, assuming the NPS authenticates both wireless and VPN connections, a different certificate should be used for the wireless policies and for the VPN policies. You may refer to RFC5216 The EAP-TLS Authentication Protocol, section 5.1 Security Claims, Notes.
So, as we talked, there may be little value in configuring a PEAP-based authentication method or EAP-TLS for user authentication for a VPN connection and not properly configure the validation of server’s certificate.
Let’s take a look on some misconfigurations in respect with the validation of server’s certificate for these authentication methods and see what error messages we are going to get, playing with various VPN protocols. The bellow details were taken on a lab comprising:
- Windows 2008 R2 RC as the RRAS server and the NPS server, a domain member machine.
- Windows 2008 R2 RC as the DC and enterprise CA(Active Directory Certificate Services role-the certification authority (CA)- and Certification Authority Web Enrollment-the service that enables the issuing of certificates through a Web browser- were installed, IIS was also installed as a required role service for Certification Authority Web Enrollment)
- and Windows 7 RC as the VPN client, non-domain member, VPN connections defined manually. Note: If I was to use misconfigured CMAK profiles created on a Windows 2008 R2 RC, the Security Alert or error messages might have looked similar, so I will not put the same screen shots bellow.
- the certificate configured on the NPS server for VPN policies was issued to rras2008r2rc.carbonwind.net and was issued by carbonwind-WIN-N22F19N1H07-CA.
Silly misconfiguration number 1 on a Windows 7 RC VPN client, a PPTP connection using PEAP-EAP-MSCHAPv2(I’ve chosen it so, as PPTP with PEAP-EAP-MSCHAPv2 will provide protection for users’ credentials against offline dictionary attacks, if one, for some reasons wants to continue with PPTP and not to move to a “safer” VPN protocol):
The CA’s certificate was not installed on the client’s machine(as we currently use PPTP and not SSTP or IKEv2 the CA’s certificate can go into the Trusted Root Certification Authorities the Current User Certificate Store for PEAP, we don’t have to install it into the Trusted Root Certification Authorities the Computer Certificate Store), so the needed CA does not appear bellow to be selected as a Trusted Root Certification Authorities and the server’s name as appears on the server’s certificate was not configured although the options Validate server certificate and Connect to these servers were selected-they are selected by default-(plus the option to not prompt new users to authorize new servers or CAs was not selected):
The Validate server certificate option instructs the client to validate the server’s certificate, at a minimum the validation is done by verifying that the server’s certificate was issued by one of the Trusted Root Certification Authorities that are listed above, the EKU of the server certificate contains Server Authentication(1.3.6.1.5.5.7.3.1), if it was not expired or it is not valid yet.
The Connect to these servers option actually specifies the expected name of the server as appears on the server’s certificate.
See Microsoft’s Certificate requirements when you use EAP-TLS or PEAP with EAP-TLS.
The Do not prompt user to authorize new servers or trusted certification authorities settings will not present an option to the user to connect to a server which presents a certificate and the name that appears on that certificate was not specified in the Connect to these servers option(assuming the CA that issued the certificate is listed within Trusted Root Certification Authorities area) or to connect to a server which presents a certificate that was not issued by the specified CA within Trusted Root Certification Authorities area and instead was issued by a different CA that is listed there, but not selected. It is highly recommended for the admin to select this option when he or she configures the VPN connection for users(either manually-by default on Windows 7, users need admin rights to modify the properties of the VPN connection, if this VPN connection was configured by the admin for all users- or with a CMAK profile).
Proceed anyway with the connection, and the bellow error appears, which is quite informative, it tells us that we did not configure the needed CA certificate within the Trusted Root Certification Authorities:
A similar misconfiguration on a Vista Ultimate SP2 RC machine(I’ve put the config screens too in ordered to see that the configuration on Windows 7 is more compact and clear):
And this error appears if we try to connect from the Vista machine, which is not useful at all:
Silly misconfiguration number 2 on a Windows 7 RC, an IKEv2 connection using PEAP-EAP-MS-CHAPv2:
This time, the CA’s certificate was installed on the client’s machine, so the needed CA appears bellow to be selected as a Trusted Root Certification Authorities, but was not selected and also the server’s name as appears on the server’s certificate was not configured although the options Validate server certificate and Connect to these servers were selected-they are selected by default- (plus the option to not prompt new users to authorize new servers or CAs was not selected):
Proceed with the connection, and the bellow Security Alert appears, which is quite informative and raises the attention level of the user(as it should), and also tells to the user what is recommended to do:
If we click the Details button, we can see why we get this alert and what we have to do about it:
A similar misconfiguration on a Vista Ultimate SP2 RC machine(I’ve used a PPPT connection on it, as there is no IKEv2 on Vista) and this “error” appears-which in fact does not appear to be an error at all or a Security Alert, it can be just a normal info message-, which may be dangerous, as it may trick an unaware user into clicking OK:
So things look pretty good on the Windows 7 RC, but still there is a potential issue, if one clicks the Connect button, the potentially wrong settings will be configured for “good” on this VPN connection, and the user will not get any warning messages the next time, this is not a one time “exception”, it’s more like a permanent “exception”:
Note: The above screen appears when the user has admin rights, if the user does not have admin rights and the connection was configured by the admin for all users, by default the user cannot change the VPN connection’s properties, it must provide admin credentials for that, however if he or she clicks the Connect button, while the connection itself will not be modified as above, for this specific user, apparently there will be no more prompts, although this behavior is not specified in the Security Alert from Windows 7 RC. If another user uses this connection too, this user will get the prompt, but again if he or she clicks the Connect button, while the connection itself will not be modified as above, apparently for he or she there will be no more prompts.
Sure, this was an IKEv2 connection and it features some extra security checks than it did in Windows 7 Beta, and so the client already verified the VPN server’s certificate during the IKE authentication, but the PEAP “behavior” is the same for PPTP for example. And this extra layer of protection actually is between the VPN client and the NPS server, during this authentication the client verifies the NPS server’s identity.
Similar behavior on the Vista Ultimate SP2 RC machine for the PPTP connection(as can be seen from the “error” Vista message, we were informed that if we click OK we will not be prompted again):
Silly misconfiguration number 3 on a Windows 7 RC, a SSTP connection using PEAP-EAP-MSCHAPv2 this time:
Now, the CA’s certificate was installed on the client’s machine, the options Validate server certificate and Connect to these servers were selected-they are selected by default-, the needed CA appears bellow to be selected as a Trusted Root Certification Authorities and was selected, and the server’s name as appears on the server’s certificate was configured but was typed incorrectly(a letter is missing). I’m still calling this configuration silly because the option to not prompt new users to authorize new servers or CAs was not selected:
Proceed with the connection, and the bellow Security Alert appears, the same we saw for the other misconfiguration:
If we click the Details button, we can see why we get this alert and what we have to do about it:
Same misconfiguration, this time on a Vista Ultimate SP2 RC client, and Vista throws this “error” that does not look like an error or a Security Alert, which may trick an unaware user into clicking OK:
Again, maybe not quite the same potential issue(as the CA was correct this time, and it is a private CA), but if one clicks the Connect button, the potentially wrong settings may be configured for “good” on this VPN connection, and the user will not get any warning messages the next time, this is not a one time “exception”, it’s more like a permanent “exception”:
Note: The same note as before(we already expected this by now), the above screen appears when the user has admin rights, if the user does not have admin rights, and the connection was configured by the admin for all users, by default the user cannot change the VPN’s connection properties, it must provide admin credentials for that, however if he or she clicks the Connect button, while the connection itself will not be modified as above, for this specific user, apparently there will be no more prompts on the Windows 7 RC. If another user uses this connection too, this user will get the prompt, but again if he or she clicks the Connect button, while the connection itself will not be modified as above, apparently for he or she there will be no more prompts.
Similar behavior on the Vista Ultimate SP2 RC client(Vista warned us about this “behavior”):
Sure, as it was with IKEv2, this was a SSTP connection and it features some extra security checks, and so the client already verified the VPN server’s certificate during, but as already said the PEAP “behavior” is the same for PPTP for example. And this extra layer of protection actually is between the VPN client and the NPS server, during this authentication the client verifies the NPS server’s identity.
Silly misconfiguration number 4 on a Windows 7 RC, an IKEv2 connection using EAP-TLS this time(sure EAP-TLS is a pretty strong user authentication compared with PEAP-EAP-MSCHAPv2 for example, but let’s see what will happen):
The CA’s certificate was installed on the client’s machine, the option Validate server certificate Connect to these servers was selected-it is selected by default-, the needed CA appears bellow to be selected as a Trusted Root Certification Authorities but a wrong CA was selected, and the server’s name as appears on the server’s certificate was not configured, the Connect to these servers option is not checked-was selected by default, but unchecked-. A user certificate stored within the Current User Certificates Store is used, and the option to not prompt new users to authorize new servers or CAs was not selected:
Attempt to connect, and we get this Security Alert:
Let’s see the details, pretty useful details and instructions what to do next:
A similar misconfiguration on a Vista Ultimate SP2 RC(for an L2TP/IPsec connection), one may be mislead by this message and click OK to continue:
Silly misconfiguration number 5 on a Windows 7 RC, a SSTP connection using PEAP-EAP-TLS this time(as already said PEAP-EAP-TLS may be the strongest user authentication available on the default Windows 7 VPN client, but let’s see what will happen):
So, due to the PEAP layer, before EAP-TLS takes place, a secure channel is established between the client and the NPS server, the bellow config is for this secure TLS channel: the options Validate server certificate and Connect to these servers were selected-they are selected by default-, the needed CA appears bellow to be selected as a Trusted Root Certification Authorities but a wrong CA was configured here, and the server’s name as appears on the server’s certificate was correctly configured(same certificate is used for the outer PEAP and the inner EAP-TLS on the NPS server), the option to not prompt the user to authorize new servers or CAs was not selected:
And the EAP-TLS authentication, the options Validate server certificate and Connect to these servers were selected-they are selected by default-, the needed CA appears bellow to be selected as a Trusted Root Certification Authorities and the correct CA was configured, but the server’s name was typed incorrectly. A user certificate stored within the Current User Certificate Store is used and the option to not prompt the user to authorize new servers or CAs was not selected:
Let’s proceed with this VPN connection:
- we get the first Security Alert related to PEAP, but we don’t know yet from this message which layer(PEAP or EAP-TLS, can’t tell because we use the same certificate for both of them-until we double-check our settings-, anyway a simple user probably would not care about such “details”) fired this Security Alert(if this was an active MITM attack, if we click terminate, the EAP-TLS authentication will no longer take place):
- if we click Connect, despite the strong warning to not continue, we get the second Security Alert related to EAP-TLS this time:
If we click Connect again, since now it was only a misconfiguration, the connection will succeed. And next time there will not be anymore prompts.
The same misconfiguration on a Vista Ultimate SP2 RC machine:
Click OK on this first message(related to PEAP, we don’t know this yet from this message, so we need to double-check our settings):
And we get the second message related to EAP-TLS this time:
Another misconfiguration, let’s say a “human” one, this time for an L2TP/IPsec connection, using PEAP-MSCHAPv2 for user authentication:
With this one, the CA’s certificate was installed on the client’s machine, the options Validate server certificate and Connect to these servers were selected-they are selected by default-, the needed CA appears bellow to be selected as a Trusted Root Certification Authorities and was selected, and the server’s name as appears on the server’s certificate was configured but was typed incorrectly(a letter is missing). The option to not prompt new users to authorize new servers or CAs was selected this time:
A connection attempt and we get this error, error that tell us that something was wrong with the PEAP authentication because of the Verifying user name and password… message:
A similar misconfiguration for an L2TP/IPsec connection on a Vista Ultimate SP2 RC and we get this error:
As can be seen this time there aren’t any major improvements or so between Vista and Windows 7 RC.
Ok, this one is not a misconfiguration on the client, but it’s interesting: a PPTP connection using PEAP-MSCHAPv2, the validation settings are correct on the client( so I’m not going to picture them again), I’ve just issued a fresh certificate to the NPS server, but the time on the client is a little “early”, there are a couple of hours difference between the time on the client and the one on the server, so to the client the server’s certificate appears to not be valid yet:
Connect and:
Well, this is not quite correct, the certificate is not expired, but at least we got something.
On a Vista Ultimate SP2 RC we got nothing for the same issue:
A simple attack now, a VPN connection using PEAP-EAP-MSCHAPv2 correctly configured in respect with server’s certificate validation, this time a rogue server is trying an active MITM attack, presenting a certificate from a rogue CA with the same name as the real CA, while the server certificate is “crafted” to look like the valid one, same name on the certificate, same etc.
As said above, the connection is correctly configured for server’s certificate validation:
If we connect, then we get this error, which is not a surprise, as we already have been here(even if the option to not prompt the user to authorize new servers or CAs would have not been selected, we would have received the same message):
So by now you may wonder why I insist on the option to not prompt the user to authorize new servers or CAs to be selected. Let’s craft another attack, another active MITM, a VPN connection using PEAP-EAP-MSCHAPv2 correctly configured in respect with server’s certificate validation but without the option to not prompt the user to authorize new servers or CAs checked.
This time a rogue server presents a certificate issued by a CA within the Trusted Root Certification Authorities(say a public CA), and this certificate is stolen from a web server, being valid(not expired, revoked or so, maybe the web server’s admins have yet to figure it out that their web server’s certificate was stolen).
I’ve manually “crafted” such a certificate with OpenSSL(nothing special, a normal web server certificate), and imported the “trusted” CA that issued the stolen certificate into the Trusted Root Certification Authorities, so we can see this CA listed:
If we proceed, well we’ve already saw this, but this time may be for “real”:
If we ignore this warning, which suddenly makes sense, and click Connect, for example, the attacker can now mount offline dictionary attacks against the user’s credentials(for the end user probably the connection can be terminated with some “normal” message, the user will try again, and this time the connection will work just fine if it will connect to the real server, so the user might not worry and not alert the admin-especially if the message from Vista was still presented instead of the Security Alert-). I’ve clicked Connect and since my VPN server knows the correct user credentials, the connection will succeed:
I’ve also made a connection like so while I was logged with admin rights in order to get the bellow screen(remember a discussion from above):
If the option to not prompt the user to authorize new servers or CAs would have been selected, no need for the user to decide anything:
Think that the above attack will fail with EAP-TLS or PEAP-EAP-TLS if the do not prompt the user to authorize new servers or CAs option was not selected ?
I’m afraid it is not so, if the user still clicks Connect. I did not see a requirement within the Certificate requirements article that when you use EAP-TLS or PEAP-EAP-TLS, the certificate presented by the server to be from the same CA as the certificate used by the client in order to be successfully validated by the client, remember that now only the checks the client performs matter, the “server” will accept anything. My quick tests seem to indicate this aspect too(apparently the “crafted” certificated is up to the standards).
For example PEAP-EAP-TLS connection(not that one would use today the weak PPTP with such a strong authentication protocol, just to visualize what will happen):
Hit twice Connect:
And now the attacker is connected to the VPN client instead of the client being connected to the VPN server:
I’ve also made such a connection while I was logged with admin rights in order to get the bellow screens(remember a discussion from above):
