The Truth About Public Wi-Fi Security (It's Worse Than You Think)

The coffee shop Wi-Fi advice has been oversimplified for years — 'use a VPN, you'll be fine.' The actual threat model on public networks is more complicated, some of the old attacks are less relevant now, and some newer ones are worse than ever. Here's what's actually going on.

The Man-in-the-Middle Reality

On a typical home network, your device connects to a router you control. On public Wi-Fi, you're connecting to someone else's hardware, on a network shared with strangers. A classic man-in-the-middle (MITM) attack intercepts traffic between your device and its destination — possible on public networks when the attacker is on the same network segment.

The widespread adoption of HTTPS has significantly reduced what a MITM can read. If you're on an HTTPS site, your traffic is encrypted end-to-end and a network-level attacker sees ciphertext. The attack surface has shifted. Unencrypted traffic — old HTTP sites, some legacy apps, certain IoT devices — remains fully exposed.

Evil Twin Attacks

An evil twin is a rogue access point set up to mimic a legitimate one. The attacker creates an open Wi-Fi network with the same name as the coffee shop's network — 'CoffeeShop_Free' — with a stronger signal. Devices that auto-connect to known networks will connect to the evil twin instead. Now all traffic goes through the attacker's equipment first.

This attack works because most devices aggressively auto-connect to previously seen networks. Disabling auto-connect for public networks removes the vulnerability. Look — the right move is deleting public networks from your saved list after you're done with them.

HTTPS Stripping and SSL Interception

SSL stripping attacks downgrade HTTPS connections to HTTP during the initial handshake, before the browser shows any warning. The victim thinks they're on a secure site; they're not. HSTS (HTTP Strict Transport Security) defeats this for sites that implement it — the browser refuses to connect over HTTP regardless. Major sites use HSTS. Not all sites do.

What a VPN Actually Fixes Here

A VPN on public Wi-Fi encrypts everything from your device to the VPN server, regardless of the underlying network. Evil twin attacks become largely irrelevant — the attacker sees an encrypted tunnel they can't read. SSL stripping can't happen on already-encrypted VPN traffic. The VPN's DNS resolver handles queries, preventing local DNS poisoning.

The one remaining risk: the VPN connection itself failing silently. A kill switch — which blocks all traffic if the VPN drops — is essential on public networks. Without it, your traffic briefly reverts to unprotected whenever the VPN hiccups.

The Captive Portal Problem

One awkward edge case with VPNs on public Wi-Fi: captive portals. When you connect to hotel or airport Wi-Fi, the network intercepts your traffic and redirects you to a login page before granting access. If your VPN's kill switch is active, the captive portal page can't load because all non-VPN traffic is blocked. You're stuck. The workaround is temporarily disabling the kill switch, completing the captive portal login, then re-enabling it — accepting that brief window of unprotected traffic.

Some VPN clients handle this automatically. Mullvad has a 'LAN bypass' option specifically for captive portals. Others require manual toggling. It's a real inconvenience, and it's why some people just don't use VPNs on public Wi-Fi at all — which is arguably the wrong call, but the friction is real. Know the limitation so you can handle it when it happens.