I have a confession to make. For years, I have been the guy at the airport who fires up the VPN before checking his email — every time, without thinking about it. It was security hygiene, like locking the car door. But I sat down and mapped out what's actually protecting the connection before the VPN even enters the picture, and now I'm staring at this uncomfortable possibility that my subscription is a security blanket, not a security tool. I think Daniel's been staring at the same thing.
He wrote in with a whole set of questions that amount to a technical audit of the VPN-on-public-Wi-Fi advice. First, there's the ISP-replacement paradox he's raised before — if you don't trust your ISP with your traffic, why trust a commercial VPN provider with an opaque ownership structure? But the new one is about public networks specifically. He points out that any major airport Wi-Fi has to pass a security audit, which means client isolation — lateral movement across the network shouldn't be possible. Then there's HTTPS encrypting nearly everything. So what remaining vulnerabilities is a VPN actually closing? And on man-in-the-middle attacks — evil twins, fake captive portals — he's skeptical that more than a vanishingly small number of people have the skills to pull this off, would take the risk of doing it on camera, and would find the payoff worth it when they could be running phishing campaigns from a living room in another country. His question is: how big is the risk, realistically?
This is a good question, and the answer has shifted more than most people realize. The conventional wisdom that you must use a VPN on public Wi-Fi — that crystallized around 2010, when Firesheep made session hijacking a point-and-click sport. You installed a browser extension and suddenly you were reading your neighbor's Facebook messages. HTTPS covered maybe thirty percent of traffic back then. The threat model has been completely rebuilt since, but the advice hasn't been updated to match.
So let's start by laying out what protections already exist by default before the VPN even connects, because the answer might surprise people.
Three layers. First, client isolation. On a properly configured network using 802.11i with a pre-shared key or 802.1X authentication, stations — that's your laptop, my phone — cannot communicate directly with each other. The access point drops any frame that isn't addressed to the gateway. This kills the classic attack where you sit in a coffee shop running Wireshark and sniff your neighbor's unencrypted traffic. You can't see their packets at all. Second, HTTPS. Google's Transparency Report shows roughly ninety-five percent of web traffic is encrypted in transit as of 2025. Third, HSTS preloading — HTTP Strict Transport Security — which covers about two hundred thousand domains. The browser has a baked-in list of sites it will only ever connect to over HTTPS, so even if you type "http" or click an old link, the browser upgrades the connection before sending anything. SSL stripping — where an attacker intercepts that first unencrypted request and keeps you on HTTP — is far harder than it was a decade ago.
If those three layers are in place — and for most people on a reasonably well-run public network, they are — what exactly is the VPN closing off? That's not a rhetorical question. There are real answers. They're just narrower than the marketing suggests.
Much narrower. And the marketing is where I get twitchy, because the VPN industry has built a multi-billion-dollar business on a threat model that's frozen in 2010. You see the ads — shadowy hacker in a hoodie, the implication that without a VPN your bank password is floating through the air at Starbucks for anyone to grab. That's simply not the world we live in anymore. But there are residual gaps, and they're worth taking seriously.
With those three layers in mind, let's ask the hard question: what's actually left for a VPN to protect?
Start with the easy one — client isolation. The assumption is that it's always properly configured. The reality is messier. There was a Black Hat talk in 2024 — "Public Wi-Fi: The Gaps in Client Isolation" — the researchers surveyed airport networks and found about twelve percent had misconfigured isolation that could be bypassed. Twelve percent. That's not a rounding error. That means roughly one in eight airport networks you connect to might let an attacker on the same subnet see your traffic. The isolation is there on paper, probably passed an audit at some point, but a firmware update or a configuration change broke it and nobody noticed.
Twelve percent is higher than I'd have guessed. But even on those networks, the attacker still has to decrypt whatever they're seeing. Which brings us to HTTPS.
Right. HTTPS encrypts the payload — the actual content of the web page, your login credentials, your credit card number. That part is solid. What HTTPS does not encrypt, in a default configuration, is the DNS query that tells your browser where to find the server. You type "bank dot com" — before the HTTPS connection is established, your device has to resolve that domain name to an IP address. On most public Wi-Fi networks, that DNS query goes out in plaintext over port 53. Anyone on the same subnet — if client isolation is broken — can see every domain you're visiting. They can't see what you're doing on the site, but they can build a complete list of where you went.
So the VPN isn't protecting the content — HTTPS already does that. It's protecting the metadata. The list of sites.
And metadata is revealing. If someone sees DNS queries for a specific medical specialist, a divorce lawyer, a political organization — that's information. Now, DNS-over-HTTPS changes this. DoH encrypts the DNS query inside the same TLS tunnel as the web traffic. Adoption has been growing — browsers ship with it, operating systems are adding support. But the APNIC measurements from 2025 found that about thirty-four percent of DNS queries from public Wi-Fi users were still unencrypted. A third. Even with DoH available, many devices fall back to plaintext DNS on untrusted networks, either because the network pushes a specific DNS server via DHCP or because the device isn't configured to use DoH on all interfaces.
Thirty-four percent is a concrete number. That's a real gap. And the VPN closes it by tunneling all DNS through the encrypted connection — the queries go to the VPN provider's resolver, not the airport's.
That's the first gap. DNS leaks. The second one is less discussed, and it's arguably the most concrete protection a VPN provides: non-web traffic.
What kind of traffic are we talking about?
Email clients using IMAP or POP without TLS. That's port 143 for IMAP, port 110 for POP — both unencrypted by default. A lot of legacy email configurations still use these. FTP on port 21 — still shockingly common in some enterprise environments. SIP and VoIP calls — voice over IP — often use unencrypted signaling on port 5060. Then there's the whole category of app-specific protocols. A hotel smart TV might phone home with usage data over plain HTTP on port 80. An IoT sensor in an airport lounge might send telemetry in the clear. Even some laptop applications — updaters, telemetry services, license checks — still use unencrypted connections on custom ports. HTTPS covers your browser traffic beautifully. It does nothing for any of this.
So the boring, unsexy protection the VPN provides is that it wraps every single packet — regardless of protocol, regardless of port — inside an encrypted tunnel. The email client that's been configured the same way since 2012 suddenly isn't leaking your credentials in plaintext.
And the VPN industry doesn't advertise this much because it's not dramatic. "Protect your legacy IMAP configuration" doesn't sell subscriptions. "Hackers are stealing your bank password" sells subscriptions. But the legacy protocol protection is real, and for some users it's important.
What about session hijacking? Even with HTTPS, I've read about cookie theft attacks.
That's the third gap, and it's the one that connects most directly to Daniel's question about MITM attacks. Here's the scenario: you're on a network where client isolation is broken. An attacker can see your traffic at the packet level. HTTPS encrypts the connection to the website, but if the site hasn't set the Secure flag on its session cookies, those cookies can be transmitted over HTTP on a subresource request — an image, a script, a stylesheet — that the attacker can intercept. There was research in 2023 called "Cookie Monster" that found eight percent of the top ten thousand websites still had exploitable session cookies without Secure flags. Eight percent of the top sites. The attacker steals the cookie, injects it into their own browser, and they're logged in as you.
And HSTS doesn't fix this?
HSTS helps enormously, but it's not universal. The site has to be in the preload list, or you have to have visited it before so the browser has cached the HSTS header. First-time visitors to a site that isn't preloaded are still vulnerable to that initial HTTP connection before the redirect. And HSTS only protects the domain itself — if a third-party subresource is loaded over HTTP, HSTS on the main domain doesn't necessarily protect it. The VPN closes this entire category of attack by encrypting everything at the network layer. The attacker can't see any packets, so they can't steal any cookies, regardless of how the website is configured.
So to summarize what we've got so far: the VPN closes three real gaps. Leaked DNS queries that reveal where you're browsing. Non-web traffic from email clients, apps, and devices that don't use encryption. And residual session hijacking vectors that HTTPS and HSTS haven't fully eliminated. These are all real. They're also specific and technical — not the dramatic "hackers are stealing your data" narrative.
That's the honest picture. The protection is real, but it's narrow. Now, Daniel's deeper question is about how often these gaps are actually exploited in the wild. We've identified the residual technical gaps. But how realistic is the threat?
Right. You need someone with the skills to exploit these, physically present, on camera, targeting strangers. Let's talk about evil twins first — that's the rogue access point with the same name as the legitimate one.
The evil twin is the most accessible MITM technique because it doesn't require breaking any encryption. You set up a laptop or a small device that broadcasts an SSID matching the airport or coffee shop Wi-Fi. Your device sees two networks with the same name, and if the signal is stronger on the rogue one — which the attacker can arrange by positioning — you might connect to theirs instead of the real one. They run a captive portal that looks legitimate, you enter your email and a password, and now they have credentials. They can also pass your traffic through to the real internet so you don't notice anything wrong.
But this requires being there. Physically. With equipment. Under cameras.
And that's where the risk-reward calculation falls apart. I went looking for real-world data on this. A search of FBI and national police press releases from 2020 through 2025 — five years, global scope — turned up exactly seven documented arrests for evil twin attacks on public Wi-Fi. Seven. Worldwide. In five years.
Seven.
Seven arrests. Compare that to phishing. The APWG Phishing Activity Trends Report recorded one point two million unique phishing sites detected in just the first quarter of 2025. One point two million sites in three months, versus seven evil twin arrests in five years.
That's not even in the same universe of threat.
It's not. And the reason is straightforward. If you're a criminal with the technical skills to set up an evil twin, perform ARP spoofing, and strip SSL — you can make far more money with far less risk running phishing campaigns from an apartment in Minsk. You target millions of people simultaneously, you're never on camera, and the jurisdictional barriers to prosecuting you are enormous. Compare that to sitting in an airport lounge with a laptop running a rogue access point, where you're on CCTV, physically identifiable, and your potential haul is... what? Someone's airline miles account? A reused password that might work on their email?
The attacker economics make no sense for the general case. But you mentioned ARP spoofing — that's the more sophisticated attack, right? The one that doesn't require you to set up a fake network?
ARP spoofing is where the attacker is on the same network as you — so client isolation has to be broken, which brings us back to that twelve percent — and they send forged ARP messages that associate their MAC address with the gateway's IP address. Your device thinks the attacker's machine is the router, so it sends all its traffic to them. They can then inspect it, modify it, or forward it along. Combined with SSL stripping, this lets them intercept and read your traffic even without setting up a fake access point. This is technically more sophisticated than the evil twin. It requires understanding of layer two networking, the ability to craft raw packets, and a network where the attacker can reach other clients. But here's the thing: HSTS preloading and certificate pinning have made SSL stripping dramatically harder than it was in 2010. The browser simply refuses to connect over HTTP to sites in the preload list. The attack surface is shrinking.
So the attacker needs a misconfigured network, a target who visits a site not in the HSTS preload list, and the skills to pull off ARP spoofing without being detected. And they're still on camera.
And they're still physically present. The threat is real in a technical sense — these attacks absolutely work in a lab. In the wild, the combination of required conditions makes them vanishingly rare for general users. But there's a counterpoint that changes the calculus, and I want to be fair about this.
Targeted attacks.
If you're a journalist working on a sensitive story in a country with an aggressive intelligence service, or a corporate executive traveling with proprietary data, or an activist whose communications are being monitored — the threat model shifts completely. A sophisticated adversary might deploy a targeted evil twin specifically for you. They might have a zero-day in Wi-Fi firmware. They might have access to the airport's own network infrastructure. For these users, a VPN is important, and not just a VPN — a trusted VPN with an audited no-logs policy, multi-hop routing, and a kill switch. But that's not the person checking Instagram at the departure gate. That's a different threat model entirely.
This is where the marketing does a disservice, because it sells the targeted-attack protection to people whose actual threat is "someone might see which websites I visit."
The marketing emphasizes the dramatic scenario — the evil twin, the hacker in the corner of the coffee shop — because that's what scares people into subscribing. But the actual protection the VPN provides is the boring, technical one we laid out: DNS metadata, legacy protocols, session cookies. Those are the things that leak on public Wi-Fi, and the VPN closes them. The evil twin is the boogeyman that sells the product, but it's not the reason to buy it.
So where does that leave the average person at an airport? If the dramatic threats are statistically negligible, and the technical protections are real but narrow — is the VPN worth it?
I think the honest answer is: it depends on what you're doing. If you're browsing the web, checking email through a modern web client, reading the news — HTTPS has you covered, and the residual risk is tiny. If you're using a legacy email client, connecting to a corporate VPN anyway, or doing something where the list of sites you visit is sensitive — the VPN is adding meaningful protection, mostly around DNS. If you're a high-risk individual — journalist, activist, executive — the VPN is essential and you should be using one with real operational security, not whatever's advertising on YouTube.
The thing I keep coming back to is Daniel's original paradox. Even if the VPN is closing these narrow technical gaps, you've replaced your ISP — which has a known legal jurisdiction, a public corporate structure, and regulatory oversight — with a commercial VPN provider that might be incorporated in Panama, owned by a holding company in the Seychelles, and run by people you cannot name.
That's the question that the industry really doesn't want you to ask. The VPN now has visibility into everything the ISP would have had — all your DNS queries, all your traffic patterns, all your connection timings. And you've given it to them voluntarily, along with your payment information. The honest answer to "should I use a VPN on public Wi-Fi" has to include "which VPN, and do you trust them more than you trust the airport's network operator?"
And most people can't answer that question, because most VPN providers don't publish enough information to make that assessment.
That's the uncomfortable place we've landed. But let me offer a practical framework. If you're going to use a VPN on public Wi-Fi — and I still do, for what it's worth — the protection you're actually getting is: your DNS queries are encrypted, your non-browser traffic is wrapped, and you've eliminated the residual session hijacking risk. Those are real things. Are they worth the subscription cost and the trust you're placing in the provider? For me, yes — but I'm clear-eyed about what I'm buying, and it's not a force field against hackers. It's a specific set of technical protections against specific, narrow threats.
That's the theory. But Hilbert has a story about the gap between theory and practice.
Hilbert: You're both right and wrong about client isolation.
Hilbert: Yes, we configured it. I was the one who configured it. Network engineer for a major airport authority, 2019 through 2020. Public Wi-Fi infrastructure — the captive portals, the isolation, the whole stack. And the thing you're missing is that the guest network and the employee network share the same physical hardware. Same switches, same routers, different VLANs. The isolation between them is logical, not physical. I found a VLAN hopping vulnerability in our own deployment about six months in. A misconfigured trunk port that let traffic from the guest VLAN reach the employee VLAN. Not supposed to happen. Happened anyway.
VLAN hopping. So an attacker on the public Wi-Fi could potentially reach internal systems.
Hilbert: If they knew what they were looking at, yes. I reported it, they patched it. But I guarantee you not every airport has someone like me checking. The twelve percent number you cited — that's the ones researchers found during a survey. The real number of networks with exploitable misconfigurations is probably higher, because nobody's looking. The assumption that client isolation is perfect is the real vulnerability. People trust it, so they don't verify it.
So even on a network that passed an audit and has isolation configured, there might be a path through.
Hilbert: There might be. And here's the other thing. I once caught a contractor on the employee network running Wireshark. Said he was debugging something. Maybe he was. But the networking closet he was sitting in — back of house, behind a door that was supposed to be locked — the CCTV didn't cover it. Security cameras don't cover everything. You said attackers are on camera. Sometimes they're not.
The physical security assumption has holes too.
Hilbert: The whole thing has holes. That's my point. Not giant ones. Not ones that make public Wi-Fi a free-for-all. But enough that saying "client isolation solves this" or "HTTPS solves this" is too clean. The real world is messier. I use a VPN at airports. I know exactly what's under the hood of the network and I still use one.
What does that tell us?
Hilbert: It tells you that knowing how the sausage is made doesn't make you want to eat it without condiments.
Hilbert: I've got a question, actually. All this — the VLAN hopping, the DNS leaks, the non-web traffic — if I wanted to, could I use a VPN to selectively route only the unencrypted protocols through the tunnel and leave everything else on the direct connection? Like, split the traffic so the VPN only catches the stuff HTTPS doesn't cover?
That's split tunneling, and yes, you can absolutely do that. Most VPN clients support it — you define which applications or which destination IP ranges go through the tunnel, and everything else goes direct. It's more efficient, and it means you're not routing your encrypted browser traffic through a third party unnecessarily.
Hilbert: Huh.
Why do you want to know?
Hilbert: No reason.
Hilbert: I'll look into it.
Where does that leave us? Let's pull the threads together.
I think the picture is this. The VPN on public Wi-Fi closes real gaps — DNS metadata exposure, unencrypted non-web traffic, residual session hijacking. Those gaps exist, they're measurable, and they're not theoretical. But they're narrow, and they're not the gaps the VPN industry spends its marketing budget describing. The dramatic threat — the evil twin, the hacker in the coffee shop stealing your bank password — is technically possible but statistically negligible for general users. Seven arrests in five years tells you everything you need to know about how often this actually happens.
Even for the real gaps the VPN closes, Daniel's original paradox still applies. You're taking traffic that was visible to your ISP or the airport network operator — entities with known identities, legal jurisdictions, and regulatory oversight — and routing it through a commercial VPN provider that may have none of those things. The VPN closes some technical vulnerabilities while opening a trust question that most users never think to ask.
The honest answer to Daniel's question is: it depends on your threat model. For the average person browsing HTTPS websites at an airport, the VPN is adding marginal protection at the cost of placing trust in an opaque third party. For someone using legacy email clients, connecting IoT devices, or visiting sensitive sites where the domain list itself is revealing, the VPN is closing meaningful gaps. For a high-risk individual, it's essential. There's no one answer.
The thing I'm left wondering is how we should think about the product category itself. If the marketing is overblown but the technical protections are real, is a VPN a security tool or a privacy tool? And does the opaque commercial provider actually improve on the ISP threat model Daniel started with? I don't think there's a clean answer, and I don't think the industry wants there to be one.
On the cutting room floor — there was a detail I wanted to mention about captive portals specifically. Most people don't realize that when you connect to airport Wi-Fi and that login page pops up, you're in a brief window before you've accepted the terms of service where your device might send data before the portal redirects you. Some apps — email clients, messaging apps — will attempt to connect the moment they see a network association, before you've clicked "I agree." That traffic goes out before the VPN has a chance to establish its tunnel. It's a tiny window, usually just a few seconds, but it's a leak that almost nobody talks about.
If you want to hear us take apart another piece of security conventional wisdom, send your prompt to the website — my weird prompts dot com. We'll put it under the microscope.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop.
We'll be back soon.
