Why You (Probably) Don’t Need A VPN

Technology


How the internet works, where you’re safe, and where you’re not.

“You should never enter a password when you’re on public wifi.”

I’ve heard that statement several times now, coming from friends, family members, and others. People have been sold on this idea that public wifi is unsafe, and by using virtual private networks (VPNs) that encrypt your data between your system and the VPN provider, you’re somehow safer. While there used to be some truth to that, the internet has changed over the years, and the reality is, for most consumers, you probably don’t need a VPN. But, to explain that, I’d like to explain a bit about how the internet works.

When you type a website into your address bar (let’s say geekdad.com), and you hit enter, here’s a (simplified) summary what happens:

  • The computer needs to find the internet address for geekdad.com – sites have numeric addresses, not human-readable names, so the first step is to make a domain name system (DNS) query, asking “hey, where is geekdad.com?” This is sent to a DNS server.
  • The DNS server replies with an internet address: “hey, you asked for GeekDad? It’s over at 144.217.105.226.
  • Your computer then sends a request to that location saying “hey, I want to load a webpage,” over Hyper Text Transfer Protocol or HTTP.
  • The website responds with “oh, sure, here’s the data that makes up this website,” or…
  • The website says, “hey, can we talk over Secured HTTP, or HTTPS, instead? Please make this request again over HTTPS (in which case your browser does, and you get the page over HTTPS instead of HTTP).

Now, let’s talk about that process for a second. Let’s say I’m some ne’er-do-well sitting in your coffee shop, trying to get your password to your bank. When you login to your bank’s website over that coffee shop wifi, here’s what could I see, assuming you don’t have any special protection in place:

  • I could see your request for the address to bank_website.com, the DNS query – that’s not encrypted.
  • I could also potentially see your initial request to the website, potentially over HTTP.
  • But, once the connection switches to HTTPS… I can’t read anything – the connection is encrypted.

Here’s the thing: in 2020, so many websites use HTTPS by default – it used to cost website operators a decent amount of money to get a certificate, the thing required to use HTTPS on your website (which would encrypt traffic to your site and to show that nice lock icon in the browser), but certificates have gotten cheap (free, actually), and HTTPS has been widely adopted (especially by any website that has a login). So even on a site like Geekdad, that isn’t your bank, you’re probably connecting over HTTPS.

For the record, your bank, unless they’re stunningly incompetent, is certainly using HTTPS. Firefox and Chrome also now show warnings if you try to login a site that isn’t using HTTPS.

All this is to say that the content of what you do online (your login information, for example) is usually pretty safe from a class of attacks called man-in-the-middle attacks (the person eavesdropping in the coffee shop). They’re also protected from your internet service provider — when you log in to Twitter, if it’s over HTTPS (and it is), even Comcast/AT&T/the owner of the café/etc. can’t see what you’re doing on the website.

What they CAN see is that you went to Twitter.com, though, for two reasons.

  • Unless you’ve configured your system to use a third-party DNS service, your computer/phone/whatever is likely sending DNS queries to a server controlled by your internet provider. So, though Comcast doesn’t know what your login was to Twitter.com, they saw your computer go “hey, can I get the address to Twitter.com please?”
  • Even if you hide that from them, they still saw you connect to 104.244.42.1 (Twitter), and even if they can’t read what you did, and they can easily figure out, “oh, you connected to this address, what service lives here… oh, that’s Twitter.”

Most parental controls actually work off the DNS system – it’s easy to simply place a filter that goes, “when someone asks for the address to [adult website here], don’t resolve it, or send back a false address, that shows a “you got blocked” message.”

Given all this – do you need a VPN? Well that’s tricky. We’ve already established that the content of what you do online is, often, pretty safe from the network operator/snooper/coffee shop owner perspective (there’s an entire bank of articles I could write on how advertisers track you online based on tracking cookies, social media logins, etc, but that’s something we’ll save for another day – and VPNs don’t help you there anyway). But, as we established, all those people can see what websites you connect to. So, when you get a VPN, what you’re trying to do is shield where you go instead of what you do.

At the end of the day, someone needs to make the connection between you and the website you want to go to. Now, that person can be your internet service provider (your ISP), or it can be your VPN provider. But, what’s to say your VPN company isn’t snooping through your traffic data, and selling it to advertisers?

You don’t know if they are – they might be deleting your traffic logs (as many VPN operators claim), or they could be selling them to the highest bidder. VPNs aren’t inherently safer – they’re just shifting who has your browsing history, from your internet provider to your VPN provider. And VPNs can get hacked too.

Now, there are things you can do to protect yourself a bit more – there’s been some talk recently about encrypted DNS, which ensures that the DNS lookups are protected. This does help – it prevents a class of attacks called DNS hijacking. In those cases, the person in the coffee shop doesn’t read your connection to your bank – instead, when you type in bank_website.com, they send back a false DNS response with a dummy website that looks like your bank. Using encrypted and secured DNS can prevent that because then you’re doing those lookups over a secure channel.

You can use encrypted DNS for free – browsers like Chrome and Firefox support it (as DNS-Over-HTTPS, or DoH) already, as does the latest version of Android, and you can use apps like the 1.1.1.1 app (by Cloudflare) to encrypt DNS traffic from your phone.

However, encrypted DNS doesn’t stop your internet provider/the coffee shop owner from seeing where you go (because, again – if they know you went to 104.244.42.1, then they can figure out who that is). Encrypted DNS is not worthless, as it helps protect you from being redirected to a malicious site, but it still doesn’t hide your history from either the ISP or the coffee shop owner.

So – when choosing if you need a VPN the question to ask is not “do I need to protect my passwords when using sites on public wifi,” but instead, “who do I trust to keep my browsing history private? Is it Comcast, or is it some VPN company?”

Personally, I don’t think that question has a good clear answer (my own recommendation would be to roll your own VPN using Algo, but that’s more work than most people want). Ultimately, the best you can do is to be mindful – and understand what is and isn’t safe online.

The featured image of this post is from Flickr user Richard Patterson (with some slight cropping), and is used under the Creative Commons License.

Liked it? Take a second to support GeekDad and GeekMom on Patreon!

2 thoughts on “Why You (Probably) Don’t Need A VPN

  1. We need more people like you getting the word out regarding the over selling of VPNs.
    My brother was wondering why his iPhone was slow. I found out he was using a VPN. I asked why, and he stated “because the advertisements convinced me”

    There is generally no reason for anyone to use a VPN. As you stated HTTPS works just fine

  2. Very good read with perspective about VPNs. The bit about HTTPS was a “smell the coffee” moment 🙂 I worked in IT support for best part of 20 years before (recently) retiring and VPNs were the defacto for road warriors but things change 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *