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?
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.
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
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.
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.
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)
1st risk: OS
The first point of which depends the security of your proposed solution is the security of your OS which is the starting point of your VPN.
Too many admins tend to forget that to use a VPN to reach his company network from a weak OS is above all a security risk, and a major one since a VPN incoming connection is usually classified as a trusted one (at the company firewall, at the company IPS, everywhere).
Here is a common reality scenario: your computer is hosted by a keylogger. (Real experience return: the usual figure is above 1. End user control with a VPN solution: the usual figure is below 1).
2nd risk: traffic beside the tunnel
A correctly configured VPN should block the Internet visibility through unencrypted traffic (i.e. normal IP). Everything should go through
ah (51 now mostly not anymore used) or
Reality scenario: your VPN configuration is up but the traffic on the wireless connection bedide the tunnel is open and nothing on the system controls it, and the admin isn't network aware enough to see it at first.
I guess you don't type
tcpdump -i en1 everytime you startup a VPN on an interface named
en1 to check that
67/udp/IP… are still flooding beside the tunnel entry :) and not just
I guess you don't check with
arp -a if any neighbour is already connected to your PC in the Wi-Fi environnment.
3rd risk: magically accepted certificates
On most OSes, users, even admins, and even security aware admins, tend to trust the automagic function of accepting a remote certificate. This function is hidden within browsers and sometimes within the OS itself. A trust you don't verify is magic. It is a risk.
When this magic implies that you have to first launch
to build your VPN, this is worth a full life of investigation and horror.
When connecting with your company on a VPN built on top of an
https connection, your company should force you to check your company's certificate to be sure you are not using one which is presented by a fake web server within your Wi-Fi neighborhood. You should have the fingerprint of your company's certificate on an independant document you could check within any situation.
This connection shouldn't be built on top of magic trust.