Public Wi-Fi: reasonable paranoia

A consultant proudly shows me his setup in a hotel lobby in Singapore: a free VPN installed the night before, because he “never trusts hotel Wi-Fi.” While he’s talking to me, his phone is busy pushing his contacts to the free VPN provider’s analytics server. The hotel’s network, meanwhile, was perfectly ordinary. The threat he feared didn’t exist; the one he’d invited was running in his pocket.

The usual trap

The dominant discourse on public Wi-Fi swings between two caricatures, and both do you a disservice. The first, from the 2010s, survives in copy-pasted awareness training: “public Wi-Fi is mortally dangerous, never open your email from a café, a hacker can see everything.” This fear has a real root — in 2014, intercepting a session on an open network was a beginner’s magic trick — but it describes an internet that no longer exists. Back then, the majority of web traffic flowed in the clear. The Firesheep extension, in 2010, let anyone steal the Facebook sessions of the people at the next table in two clicks. That’s the world that shaped the “public Wi-Fi = absolute danger” reflex.

The second caricature is the exact opposite, and it’s gaining ground: “HTTPSSecure HTTP encrypting browser-server communication via TLS.See glossary is everywhere now, everything’s encrypted, public Wi-Fi is no longer a problem at all.” That’s false in the other direction. HTTPS did indeed collapse the historical attack surface, but it doesn’t cover everything, and some residual vectors are precisely the ones nobody watches because we’ve decreed the matter settled.

The right position is neither panic nor carelessness. It’s reasonable paranoia: knowing exactly what’s protected today, what isn’t, and calibrating your behaviour according to the real context — a café in Lyon is not the Wi-Fi of an industry conference in Shenzhen. The problem with both dominant discourses is that they propose an absolute rule. But there is no absolute rule. There’s a threat model, and it depends on who you are and where you are.

What HTTPS really changed — and what it didn’t touch

Let’s be precise about the mechanics, because everything else flows from there. Before HTTPS became ubiquitous — say, before 2018 for critical mass — an attacker present on the same network could read the exact content of your pages, capture your credentials in the clear, inject code into the pages you visited, and steal your session cookies to impersonate you. It was trivial. Today, more than 95% of web traffic loaded in Chrome and Firefox is HTTPS. The content travels end-to-end encrypted between your browser and the server. An attacker sniffing the café Wi-Fi sees encrypted noise heading toward IP addresses. They don’t read your Gmail, they don’t steal your password over a valid HTTPS connection.

It’s a massive, real advance, and it needs saying clearly: sending a work email from a hotel’s Wi-Fi, over a valid HTTPS session, does not compromise the content of that email. This isn’t a reassuring approximation, it’s the cryptographic reality. The generic fear that “they can see everything” is obsolete.

But HTTPS doesn’t encrypt everything, and that’s where the nuance counts. What it leaks, even when working perfectly: the connection metadata. The observer on the network doesn’t see the content of your banking session, but they see that you’re talking to your bank’s domain, at what time, for how long, and at what volume. This leak passes through two channels: DNSSystem resolving domain names to IP addresses. Vastly underestimated surveillance vector.See glossary, if your name-resolution requests go out in the clear — which is still the default on many configurations — and the SNI field (Server Name Indication) of the TLSTransport encryption protocol, basis of HTTPS and modern web security.See glossary handshake, which announces in the clear the name of the server being visited at the very start of the encrypted connection. Encrypted Client Hello (ECH) is beginning to close this last hole, but its deployment remains partial in 2026.

Beyond metadata, several categories of traffic still escape HTTPS protection. Captive portals, by construction, are served in the clear. Some mobile apps still make internal APIData about data: who wrote what, when, where, to whom.See glossary, analytics, or update calls over unencrypted HTTP — the ubiquity on the browser side says nothing about badly-coded apps. The old mail protocols without explicit TLS (IMAP/POP3/SMTP in the clear) still linger in forgotten enterprise configurations. And sites that don’t implement HSTSHTTP header forcing HTTPS for future domain visits.See glossary remain exposed to an SSLstrip downgrade: an attacker in a MITMAttack where an actor interposes between two parties believing they're communicating directly.See glossary position forces the connection back to HTTP before the browser has locked in HTTPS. The big platforms are preloaded into browsers’ HSTS lists and therefore protected; your vendor’s less-common site, much less so.

The real threat model, vector by vector

Let’s stop waving the abstract fear of the “café hacker” and list the concrete vectors that remain exploitable in 2026. They fall into a few families, in decreasing order of real frequency.

The malicious captive portal. This is the most underestimated vector, by far. When you join a hotel, airport, or train Wi-Fi, you land on a captive pageOpen or shared Wi-Fi (hotel, cafe, conference) — specific threat model.See glossary — welcome, terms acceptance, code entry. This page is served over HTTP. A hostile network can present a counterfeit portal that asks you to “authenticate” with your email address and a password, or that invites you to install a “security certificate” to access the internet. That certificate, once installed, allows your HTTPS traffic to be decrypted — it turns your own device into an accomplice of the MITM. The rule is simple and absolute: a room code, at a pinch. Your credentials, never. A certificate, never.

The evil twin. An attacker deploys an access point with the same SSID as an expected network: Airport_Free_WiFi, Starbucks_Guest, ConferenceWiFi. Your device, if it has memorized a network of that name, may connect to it automatically and silently. Once on this attacker-controlled network, everything else — DNS spoofing, counterfeit portal, downgrade attempt — becomes trivial because they control the infrastructure. That’s why automatic connection to open networks is a bad idea, and why purging memorized networks is not vanity.

DNS spoofing. Without active DoHProtocol encrypting DNS requests inside HTTPS, hiding them from the ISP.See glossary or DoTDoH variant using direct TLS on port 853.See glossary, your resolution requests go out in the clear and the network can answer them as it pleases. You type your bank’s name, the hostile resolver returns the IP of a fake page. In theory, HTTPS saves you: the fake page’s certificate won’t validate, and the browser will show a warning. In practice, a non-negligible fraction of users click “continue anyway.” DNS encryption removes this vector at the root.

WPA2 with a shared key. The technical detail almost nobody knows: on a WPA2-PSK network where all clients share the same password — the standard case for hotels and cafés — a client who knows that password and has captured a victim’s association handshake can derive their session key and decrypt their WPA2 traffic. In other words, a network “protected by a password” shared among 200 people is, with respect to those 200 people, hardly more private than an open network. WPA3 (with SAE) fixes this, but remains a minority in the hotel estate.

Traffic fingerprinting. Even under VPN and HTTPS, a passive observer can analyze timing patterns, volumes, and packet sequences to infer your activity. It’s a sophisticated attack, relevant for genuinely exposed profiles and state-level adversaries, not for the average business traveler. I mention it to be honest about the upper bound of the model, not to feed anxiety.

The right approach: calibrate, don’t ritualize

The pragmatic shift consists of giving up the search for THE universal rule and reasoning by the risk level of the moment. Public Wi-Fi is neither dangerous nor safe in the absolute; it is so depending on what you’re carrying, who you are, and the jurisdiction you’re in. Three measures actually change something, and they cost almost nothing; the rest is folklore.

First, encrypt your DNS at the system level. This is the most cost-effective and most neglected measure. DoHProtocol encrypting DNS requests inside HTTPS, hiding them from the ISP.See glossary or DoTDoH variant using direct TLS on port 853.See glossary enabled makes DNS spoofing and the leakage of your resolution requests to the network operator disappear in one move. It’s configured once, at the OS level, and it protects you on every network afterwards — not just public Wi-Fi. It’s security that doesn’t depend on your discipline of the moment, so it holds.

Second, treat the captive portal as a hostile zone by default. Never enter a credential reused elsewhere, never install a certificate, and ideally open the portal in a dedicated window rather than letting your main browser wander into it. Most “via public Wi-Fi” compromises are not cryptographic feats: they’re people who typed their password into a fake page.

Third, choose the right channel according to the stakes. For a genuinely sensitive session, public Wi-Fi isn’t the problem to solve — it’s the channel to avoid. 4G/5G tethering or a local eSIMIntegrated reprogrammable SIM card supporting multiple carrier profiles.See glossary gives you a network you control, without an evil twin or a captive portal. The VPNEncrypted tunnel between your device and a server, masking your IP and traffic from your ISP.See glossary has its role — it encrypts transit and closes the local-network vector — but on two often-forgotten conditions: it must be activated before joining the network (otherwise your IP and your first DNS requests have already gone out in the clear), and it must not be a free VPN, whose business model is precisely to monetize what you think you’re protecting.

The essence of this approach fits in one idea: you don’t secure public Wi-Fi by adding anxious rituals, you secure it by putting in place two or three protections that work without you having to think about them, then by reserving the heavy measures for the contexts that genuinely justify them.

What this means concretely

Mistakes we see all the time

• “The five-star hotel is safer than a café.” No relation. Big hotels that host interesting profiles are more attractive targets, not more protected ones. The quality of the room service says nothing about the security of the network.
• “The network has a password, so it’s encrypted for me.” On shared-key WPA2, the other clients who know the password can potentially decrypt your traffic. A password shared by 200 people doesn’t isolate you from those 200 people.
• “I’ll turn on the VPN once I go to an important site.” Too late. Your real IP and your first DNS requests have already gone out. The VPN is activated before joining the network, otherwise it arrives after the battle.
• “HTTPS is everywhere, I’ve nothing left to do.” HTTPS protects the content, not the metadata, not the captive portal, not the apps quietly doing HTTP, not the sites without HSTS facing an SSLstrip.
• “The free VPN protects me.” A free VPN’s business model is to monetize your traffic. You replace a hypothetical threat on the local network with a certain threat at the provider.
• Installing the portal’s “security certificate” to save time. That’s giving the attacker the ability to decrypt all your HTTPS. Never.

Actionable checklist

• N1 Check the padlock and the validity of the HTTPS certificate before entering any credential
• N1 Never enter a reused credential or install a certificate on a captive portal
• N1 Enable encrypted DNS (DoH or DoT) at the system level on all devices
• N1 Turn off automatic connection to open networks and purge memorized networks
• N1 Turn off Wi-Fi when not in use (anti-tracking and anti-evil-twin)
• N2 Activate the VPN BEFORE joining the network, never after — and paid, never free
• N2 Prefer 4G/5G tethering or a local eSIM for sensitive sessions
• N2 Check for the absence of a DNS leak when the VPN is active
• N2 Push encrypted DNS and an enterprise VPN via MDM with automatic activation outside the corporate network
• N3 4G/eSIM-only policy for devices with sensitive data in a conference/trade-show context
• N3 Dedicated device without critical data for exposed profiles in a jurisdiction with mature interception

Going further

The Wi-Fi Alliance documents what WPA3 (SAE) brings over WPA2, useful for understanding why a shared password doesn’t isolate clients from one another. The NCSC publishes guidance on using public networks safely while working on the move, which aligns the Wi-Fi posture with the rest of travel preparation — worth reading if you’re building a corporate policy.

Three articles complete this one on the same vectors. DNS: hardening name resolution details the DoH/DoT configuration that closes the most cost-effective vector. VPN: 95% of the marketing is false explains precisely what a VPN protects, what it doesn’t touch, and which providers deserve your trust. And eSIM for travel covers the simplest replacement channel when you want to plain and simply avoid the hotel’s network. Reasonable paranoia isn’t a mood, it’s a configuration: once these three pieces are in place, public Wi-Fi becomes what it should always have been — an ordinary service, neither miraculous nor terrifying.