Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

On my work laptop I regularly create a VPN connection that I use to remote desktop to our web server. Is this safe to do on a coffee shop where random people are connected to the same wifi network?

share|improve this question

6 Answers 6

up vote 13 down vote accepted

Yes, a VPN connection encrypts the connection between your computer and the remote VPN host. The connection would just look like gibberish to anyone sniffing the traffic, either in the coffee shop or on the Internet. It is worth noting that the same applies to any content sent over HTTPS even if you aren't using a VPN.

It is also worth noting that if you are using the current version of Microsoft Terminal Services (ie remote desktop), the VPN connection isn't even strictly necessary (from a security stand point) as the remote desktop connection itself is also encrypted. Note that this setting can be optionally reduced by administrative configuration on the network though, so the VPN still isn't a bad idea.

share|improve this answer
1  
It should be mentioned, that VPN does not imply encryption by definition. –  Manuel Faux Nov 28 '12 at 18:27
    
@Manuel Faux - While technically correct, are there any commonly used VPN types that do not provide end-point to end-point protection in some form or another? I wasn't aware of any, but I'm always interested in furthering my knowledge if you know of some, and yes, something that did not could be called a VPN if it acted to make a private network across a shared network. –  AJ Henderson Nov 28 '12 at 19:40
    
It seems to some default configuration of some PPTP implementations have encryption as optional by default. As usual, good configuration is key. –  Bruno Nov 28 '12 at 21:08
1  
@AJHenderson, eg MPLS or L2TP, but to be honest both don't seem relevant for the concrete question. –  Manuel Faux Nov 29 '12 at 21:24

As has already been said - it is 'safe' to use VPN on a public wireless network. VPN uses certificates to establish an encrypted data stream between your computer and the VPN server. You can use a tool such as wireshark to verify this. However, I think there is some possibility of insecurity at least in theory. Someone COULD create a fake access point with the same SSID as the real access point and perform a man-in-the-middle attack - for SSL VPN anyway. You'd have to get a stronger signal from the fake AP in order for your computer to choose that one over the real one too.

See the following link for details: Mitigating SSLStrip attack methods on the Secure Access SSL VPN

share|improve this answer
2  
SSLStrip shouldn't work against a SSL based VPN because SSL doesn't actually attack the SSL connection, but rather prevents the client from requesting an SSL session in the first place. As long as you actively engage an SSL session or VPN connection, SSLStrip can't attack it and a rogue AP would not make a difference as the connection would still be encrypted going across it. –  AJ Henderson Nov 27 '12 at 20:19
3  
Ah, I see what they are saying, if you were using a web gateway and accessed it on an unsecured connection initially, it could strip the request to move to SSL and then establish a connection with the server via the credentials you supply, but this would require initially connecting to the VPN via insecure means, which is generally bad practice for a VPN connection anyway. –  AJ Henderson Nov 27 '12 at 20:23
    
It seems like Juniper is talking about a client in that KB article (ive.com). Is that correct, or is IVE a company that offers VPN services and is affiliated with Juniper? –  makerofthings7 Nov 28 '12 at 5:53
    
@AJHenderson Yes, SSLStrip doesn't work against VPN connections –  anhldbk Nov 28 '12 at 9:53
1  
@anhldbk yeah, the original linked article was talking about an HTTP gateway to connect to an SSL VPN. Kind of a weird way to go about it, but in that particular case, SSLStrip would work since it could be made to never start. The attacker could then use the hijacked credentials to establish a VPN and make a simple proxy to them so it would appear like the VPN was functioning if it didn't have a good security indicator. If so, it's just about the worst VPN client design ever, but still would be vulnerable. Any other VPN wouldn't be though. –  AJ Henderson Nov 28 '12 at 13:52

It depends on how your VPN is set up. If your client verifies the server identity, for example by using certificates, then yes. If it does not, you can still be MITM-ed.

share|improve this answer

In regards to @AJ Henderson's answer saying that VPNs may not be necessary for "current version of terminal services", you should know that even if the client is "newest" one available an AD setting within Group Policy can weaken security and make Wifi scenarios unsafe. This is often done as a tradeoff to enable broader functionality.

share|improve this answer
    
You raise a valid point. Updated my answer accordingly. I thought that it would still use the higher quality connection if available, but it is ambiguous enough that a general answer probably should indicate that the combination of VPN and MSTSC will be more secure even if only for defense in depth. –  AJ Henderson Nov 28 '12 at 13:48

VPN suits your needs as long the following requisites are met:

  • The VPN entry node is authenticated by you for example with a updated certificate
  • The certificate is secure (there are problems with certificates namely MD5 sign of certificates has been proved to be weak)
  • The authentication mechanism of the VPN is secure (there has been reported some issues with some authentication mechanisms namely MS-CHAP v2)
  • The channel encryption mechanism is secure (I'm not aware of know flaws)
share|improve this answer

This really depends on the kind of VPN you're using. It would have to be configured properly on both sides (client and server, when this terminology is applicable).

  • Some PPTP servers don't provide any encryption by default. In addition, you would have to make sure you're using the appropriate form of authentication (see this advisory for example).

  • OpenVPN and IPsec (in some cases) use X.509 certificates to authenticate the server (at least). This would partly suffer from the same PKI problems that affect HTTPS.

    You need to make sure you verify the remote party's certificate correctly when connecting (as always with certificates); more specifically, it needs to verify that the certificate is trusted and that its name matches what you're looking for. Correct implementations should perform these verifications.

    You may also encounter the rogue/compromised CA problem, but I would think (hope) this is rather rare. In doubt, narrow down the list of trusted CAs on your machine if you can.

  • IPsec with a shared secret. These can be fine, as long as the shared secret is more secret than shared. The knowledge of this shared secret can allow a MITM to impersonate the server (the links on that page should also be of interest).

    The larger the organisation is, the harder it seems it would be to keep that shared secret sufficiently secret. A quick search for VPN instructions for various universities seem to indicate that some of these secret are actually made public.

    Despite the PKI problems, a certificate-based solution would make it more difficult to impersonate the server, since the certificate's matching private key wouldn't be shared with any user.

So, yes, a VPN can protect you on an untrusted network (at least to the extent of the remote VPN network), but like everything, it needs to be configured appropriately.

share|improve this answer
    
In the context of this answer it's also prudent to note that if you are using a 3rd-party VPN service, either 'free' or paid, you should be aware that: 1. You data is no longer 'protected' between the endpoint of the VPN provider and the target service you're attempting to access. 2. Your VPN provider itself can very easily eavesdrop on your traffic. –  Sammitch Nov 28 '12 at 22:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.