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?

  • What do you already check?
    – dan
    Jul 5, 2015 at 9:03

7 Answers 7


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.

  • 6
    It should be mentioned, that VPN does not imply encryption by definition. Nov 28, 2012 at 18:27
  • 1
    @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. Nov 28, 2012 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, 2012 at 21:08
  • 1
    @AJHenderson, eg MPLS or L2TP, but to be honest both don't seem relevant for the concrete question. Nov 29, 2012 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

  • 3
    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. Nov 27, 2012 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. Nov 27, 2012 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? Nov 28, 2012 at 5:53
  • @AJHenderson Yes, SSLStrip doesn't work against VPN connections
    – anhldbk
    Nov 28, 2012 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. Nov 28, 2012 at 13:52

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.

  • 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. Nov 28, 2012 at 13:48

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.

  • 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, 2012 at 22:06
  • I love "Correct implementations should perform these verifications." :).
    – dan
    Jul 5, 2015 at 9:01

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)

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.


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 esp (50) ah (51 now mostly not anymore used) or 443/tcp/IP aka https.

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 53/udp/IP, 67/udp/IP… are still flooding beside the tunnel entry :) and not just 500/udp/IP.

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 Internet Explorer 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .