Public Wi-Fi: reasonable paranoia

In 2015, the Defcon conference was demonstrating how to intercept Wi-Fi sessions in a matter of seconds. In 2025, 95% of web traffic is over HTTPS. The threat still exists, but it has radically changed shape.

The common trap — two symmetric errors

There are two opposite mistakes, and both are common.

The old error: “Public Wi-Fi is mortally dangerous, never work from a coffee shop.” This fear is largely outdated. It dates from an era when the majority of web traffic traveled in plaintext. That’s no longer the case.

The new error: “HTTPS is widespread, public Wi-Fi is safe.” No. HTTPS has dramatically reduced the attack surface, but real, exploitable threats remain. Underestimating them is as dangerous as overstating the old ones.

The correct position is in the middle: understand precisely what is protected, what isn’t, and calibrate your behavior accordingly — rather than applying absolute rules in either direction.

What HTTPS actually changed

Before HTTPS became widespread (roughly pre-2018 for critical mass), an attacker on the same Wi-Fi network could:

• Read the exact content of your web pages in plaintext
• Intercept your usernames and passwords in plaintext
• Inject malicious code into the pages you visited
• Capture your session cookies and impersonate you on services

With HTTPS generalized, all that content is end-to-end encrypted between your browser and the server. An attacker intercepting your traffic at the coffee shop sees encrypted noise. They can’t read your email. They can’t steal your Gmail password if you’re connecting over HTTPS.

This is a massive, real improvement. Sending a professional email from a hotel’s Wi-Fi, over HTTPS, does not compromise the content of that email. That’s a fact, not an approximation.

The real residual threats

But HTTPS doesn’t protect against everything. Here are the vectors that remain concrete in 2026.

Malicious captive portals. When you connect to hotel or airport Wi-Fi, you typically land on a captive portal — a welcome page asking you to accept terms or enter a code. This page is served over HTTP, without HTTPS. A malicious network can present a counterfeit captive portal to steal credentials (if the page requests an email and password login) or to get you to install a “security certificate” that subsequently allows interception of your HTTPS traffic.

DNS spoofing. If you’re not using DoH or DoT (see the dedicated article), the network can redirect your DNS queries. You type gmail.com, the malicious resolver sends you to a fake page. With HTTPS, your browser should display an invalid certificate warning — but many users click “proceed anyway.”

Evil twin / rogue access point. An attacker creates a Wi-Fi access point with the same SSID as a known network (“Airport_Free_WiFi”, “HotelGuest”). Your device, if it has that network memorized, may connect automatically. On this attacker-controlled network, DNS spoofing and malicious captive portals are trivial.

ARP poisoning / Man-in-the-Middle. On an unsegmented local network, ARP poisoning redirects another client’s traffic through the attacker’s machine. With HTTPS, the attacker can’t decrypt the content — but can force HTTP downgrades on sites that don’t support HSTS, or conduct SSL stripping attacks on flawed implementations.

Unencrypted mobile applications. Some apps still make plaintext HTTP calls in 2026, especially for internal APIs, analytics, or auto-updates. These flows are vulnerable to interception on shared Wi-Fi.

Traffic fingerprinting. Even with a VPN and HTTPS, a passive observer on the network can analyze timing patterns, packet volumes, and sequences to infer information about your activity. This is a sophisticated attack — relevant for truly exposed profiles, not for the standard business user.

Protocols that remain vulnerable even in 2026

WPA2-PSK shared networks. Hotel or café Wi-Fi that hands out a single password to all clients uses WPA2-PSK (Pre-Shared Key). Technically, a client who knows this password can decrypt other clients’ WPA2 traffic if they captured the association handshake. This becomes harder with WPA3 (SAE), but WPA3 remains a minority in hotel and café deployments in 2026.

Non-HTTPS applications. Some legacy enterprise software, some email protocols (IMAP/POP3/SMTP without explicit TLS), some internal company tools still generate unencrypted traffic. On shared Wi-Fi, this traffic is exposed.

Sites without HSTS. HTTPS sites that don’t implement HSTS (HTTP Strict Transport Security) can be downgraded to HTTP by an SSLstrip-style attack. Modern browsers have preloaded HSTS lists for major services, but less prominent sites remain vulnerable.

Pragmatic routine by level

Level 1 — For everyone:

• Always verify the HTTPS padlock in the address bar before entering any credentials
• Never enter a password on a captive portal page
• Disable automatic connection to known Wi-Fi networks (this setting is typically enabled by default)
• Prefer your 4G/5G mobile hotspot for sessions involving sensitive data

Level 2 — Business travelers, sensitive data:

• VPN active before connecting to any public Wi-Fi (not after — your IP is already exposed)
• DNS via DoH or DoT configured at the system level
• Disable Wi-Fi when not in use (prevents probing of memorized networks and Wi-Fi tracking by commercial networks)
• Periodically clear the list of memorized Wi-Fi networks

Level 3 — Exposed profiles, sensitive missions:

• Never use public Wi-Fi for genuinely sensitive sessions
• Exclusively use mobile hotspot or local eSIM
• If trusted enterprise or hotel Wi-Fi is required: VPN to a controlled infrastructure with internal DNS

What doesn’t work the way you think

“The five-star hotel is safer than a coffee shop.” Not necessarily. Large hotels are attractive targets for compromising Wi-Fi infrastructure (many clients, interesting profiles). The security quality of a hotel’s network has zero correlation with its star rating.

“The network has a password, so it’s secure.” A WPA2 network with a password shared across hundreds of clients is, technically, almost as vulnerable as an open network — every client who knows the password can theoretically decrypt other clients’ traffic.

“I’ll enable the VPN when I go somewhere sensitive.” Too late. Your real IP is already visible from your initial connection. And your device may have already made DNS queries before VPN activation.

• N1 Verify HTTPS padlock before entering any credentials on any page
• N1 Never enter login credentials (email + password) on a captive portal page
• N2 Disable automatic connection to memorized Wi-Fi networks
• N2 Activate VPN BEFORE connecting to public Wi-Fi
• N2 Configure DoH or DoT at the system level (see DNS article)
• N2 Disable Wi-Fi when not in use (battery savings + privacy)
• N2 Periodically purge the list of memorized Wi-Fi networks
• N3 For sensitive data: use exclusively mobile hotspot
• N3 On mission: never use hotel Wi-Fi for strategic sessions