VPNs: What They Actually Protect — and What They Don’t
A consumer VPN does one thing precisely: it moves the first hop of your traffic from a network you did not choose to a company you paid. Whether that is an improvement depends on which of the two you trust less. Most VPN marketing skips that question, which is why the industry’s claims have drifted so far from what the technology does.
Start with the threat model, not the product
“Is a VPN secure?” is not answerable. “Who are you hiding what from?” is. Work down the list of parties who can see something about your traffic, and it is obvious which ones a tunnel removes.
What HTTPS already does
This is the part the ads never mention. On an HTTPS connection — now the default across the web, with browsers flagging plain HTTP as insecure — every page, form, credential and cookie is already encrypted end to end between your browser and the server. The café’s router cannot read it. Neither can your ISP, another guest on the Wi-Fi, or anyone tapping the fibre in between.
What HTTPS leaves visible is metadata: the destination IP address, and the server name in the TLS handshake. An observer on your network sees that you connected to a particular site and roughly how much data moved, not which pages you read or what you typed. The TLS extension designed to hide the server name too — Encrypted Client Hello — exists but is still being deployed.
What a VPN adds
A VPN encrypts everything between your device and the VPN server, including that metadata. So the specific things it hides are:
- From your ISP and local network: which sites you visit. They see one encrypted flow to one endpoint.
- From websites: your real IP address, and with it your approximate location and your ISP’s identity.
- From anyone on a shared network: traffic from applications still using unencrypted protocols — legacy email clients, some IoT devices, network file shares, plain HTTP.
And the thing it does not do, stated plainly: the VPN provider now sees everything your ISP used to. You have not removed an observer. You have chosen a different one, moving from an entity your regulator can name to one incorporated who knows where.
The leaks that undo it
Two failure modes send traffic outside the tunnel without any warning to the user.
DNS leaks. If your device keeps using the local network’s resolver while the rest of your traffic goes through the tunnel, your lookups — an excellent proxy for browsing history — are still visible locally. Well-built clients push their own resolver and block alternatives. Encrypted DNS at the operating-system level, using DNS over HTTPS as specified in RFC 8484, helps here independently of any VPN.
IPv6 leaks. A client that tunnels IPv4 and ignores IPv6 sends IPv6-capable traffic straight out of the local interface. On a dual-stack home or mobile network, that is a large fraction of traffic to major sites.
These are not hypothetical. A study by Ikram, Vallina-Rodriguez, Seneviratne, Kaafar and Paxson presented at the 2016 ACM Internet Measurement Conference examined 283 Android apps requesting VPN permission, drawn from a corpus of more than 1.4 million Play Store applications. It documented insecure tunnelling protocols, IPv6 and DNS traffic leakage, apps actively performing TLS interception, and apps injecting JavaScript for tracking, advertising and redirecting e-commerce traffic to partner sites. The VPN permission is a licence to read all of a device’s traffic, and a meaningful share of the apps holding it were using it.
The three protocols worth knowing
| WireGuard | OpenVPN | IPsec / IKEv2 | |
|---|---|---|---|
| Origin | Jason Donenfeld, NDSS 2017; in Linux since kernel 5.6 | Open-source project, TLS-based, long-established | IETF standards; IKEv2 is RFC 7296 (2014) |
| Where it runs | Kernel | User space | Kernel |
| Crypto | Fixed suite: Curve25519, ChaCha20-Poly1305, BLAKE2s, HKDF | Negotiable via TLS; wide algorithm choice | Negotiable suites |
| Complexity | Under 4,000 lines for the Linux implementation | Large, inherits the whole TLS stack | Large; historically hard to configure |
| Practical strength | Speed, battery life, roaming between networks | Can run over TCP/443 and look like ordinary web traffic | Native support on most phones and laptops; fast reconnection |
WireGuard’s design argument is worth reading in the original. Donenfeld’s paper argues that a fixed, non-negotiable cipher suite eliminates an entire class of downgrade and misconfiguration bugs, and that a code base small enough to audit is itself a security property. Its cryptokey routing binds a peer’s public key to the source addresses it may use, collapsing authentication and routing into one table. The Linux kernel merged it in version 5.6, released on 29 March 2020.
It also has a privacy wrinkle: in plain form it assigns each peer a static tunnel IP address and keeps it — convenient for a corporate deployment, unhelpful for a provider promising not to link sessions to users. Providers layer their own address-rotation systems on top. That layer is theirs, not the protocol’s, and it is one of the things worth reading an audit report about.
“Military-grade encryption” and other noise
AES-256 is a NIST standard, FIPS 197, and the NSA’s Commercial National Security Algorithm Suite approves it for classified information. It also secures your bank’s website and every HTTPS connection your phone made today. “Military-grade” describes a cipher that is universal, free and about as differentiating as advertising that a car uses petrol.
A few more claims to discount:
- “Complete anonymity.” Browser fingerprinting, logins, cookies and payment details identify you regardless of source IP.
- “Blocks hackers.” A tunnel does not patch software, stop phishing or remove malware. It changes where your packets emerge.
- “Server count.” Thousands of virtual locations on rented hardware is a marketing number. Whether servers run diskless from RAM, and who has physical access, is the real question.
- “Faster internet.” An encrypted detour makes things slower, except where an ISP throttles by protocol or your default route is genuinely bad.
Logging claims, and why audits are the only evidence
Every provider claims not to keep logs. The claim is unfalsifiable from outside — until a court asks.
The documented case worth citing is PureVPN in 2017. An FBI affidavit in a United States cyberstalking prosecution recorded that the provider could determine that its service had been accessed by the same customer from two originating IP addresses, one at the suspect’s home and one at his workplace. The company’s marketing said “no logs”; its actual privacy policy disclosed that connection times and bandwidth were recorded. Both statements were technically compatible, which is exactly the problem.
An independent audit is not proof of good behaviour, but it is the only external evidence that exists. A useful one names the auditor, states its scope, publishes the findings in full, and is repeated. Mullvad’s fourth infrastructure audit, carried out by Cure53 over 3–14 June 2024, is a reasonable model: a defined scope covering an OpenVPN server, a WireGuard server and the deployment code, one medium and one low-severity finding plus three informational ones, all remediated, with the full report published by the auditor rather than summarised by the vendor. Compare that against an “audit” that is a one-page letter with no findings section.
Split tunnelling
Split tunnelling sends some traffic through the VPN and the rest straight out. It is genuinely useful — routing a work application through a corporate tunnel while video calls and streaming go direct saves bandwidth and latency — and it is a hole in the threat model by design. Anything outside the tunnel is visible to the local network and your ISP as usual. If you turned the VPN on for privacy rather than access, split tunnelling undoes most of the reason you did.
The practical version
A VPN is the right tool in a few specific situations: reaching an internal corporate network; protecting devices or applications that still use unencrypted protocols on a network you do not control; keeping your browsing off the record of an ISP, employer or accommodation provider; and shifting your apparent location for region-licensed content, within whatever terms of service apply.
It is the wrong tool for anonymity from a determined adversary, for protection against malware or phishing, and for anyone who has not consciously decided the provider is more trustworthy than the network they are already on. If you do use one, verify the DNS and IPv6 behaviour after connecting, prefer providers who publish complete third-party audits, and read the privacy policy rather than the homepage — the gap between the two is where the interesting information usually is.