The standard advice about public WiFi safety is ten years old. In 2026, almost every site uses HTTPS, your phone refuses unsigned WiFi, and the dramatic “man-in-the-middle” demos from old talks no longer work the way they used to. That doesn’t mean public WiFi is safe — it means the actual risks have shifted, and the advice should too.
What’s actually risky on public WiFi in 2026 — HTTPS-everywhere has changed the picture
A decade ago, the coffee-shop WiFi warning was simple and accurate: your traffic was unencrypted, and anyone on the same network could read it. The 2010 Firesheep browser extension made this viscerally clear — it let anyone harvest session cookies from Facebook, Twitter, and dozens of other sites over open WiFi with two clicks. The tool spread panic precisely because it worked.
What made Firesheep possible was HTTP. Most sites in 2010 served their pages over plain, unencrypted HTTP. Authentication cookies rode that same unencrypted channel. If you could capture packets on the network, you could lift those cookies, and lifting a session cookie means becoming that user, at least until the session expired. It was genuinely dangerous.
That specific attack is largely dead. HTTPS is now universal — browsers flag non-HTTPS sites with warnings, modern platforms redirect HTTP to HTTPS automatically, and browsers enforce strict policies about what content can load over unencrypted connections. Your bank’s app pins certificates at the application layer, meaning even if an attacker intercepted the connection, they’d hit a cryptographic wall before reaching anything readable. The “sniff your bank password on open WiFi” scenario that dominated privacy writing for a decade is no longer the realistic threat it once was.
This is real progress and it’s worth acknowledging. The baseline security of using the web on a public network is meaningfully better than it was in 2015. Anyone still writing “all your traffic is visible on public WiFi” as a flat statement in 2026 is working from an outdated threat model.
What HTTPS-everywhere didn’t fix is the question worth asking. Encrypted content doesn’t mean invisible connections. And the remaining surface area is more subtle than the old attacks — which is exactly why it goes underestimated.
The remaining real attacks
Four categories of attack still work in 2026, and none of them require breaking HTTPS.
Captive-portal phishing. You join the WiFi at a hotel or airport. A page loads asking you to accept terms, log in with a room number, or create an account. This is the captive portal — the gateway that public networks use to manage access. Attackers create fake versions of these portals that look identical to the real thing but harvest whatever credentials you enter. Some push a “required security update” or a malicious browser extension. Because users have been trained to expect these gateway pages on public WiFi, compliance rates are high. The attack requires physical proximity (or just broadcasting a network with a similar name in the same space) and no technical sophistication beyond a convincing HTML page.
Rogue access points, also called “evil twins”. An attacker creates a WiFi hotspot with the same name — same SSID — as the real network in the venue. If your device has connected to that network name before and has it saved, it may auto-join the attacker’s hotspot. On the attacker’s network, they’re the DNS resolver, the gateway, and a passive observer of everything your device sends out. Not everything is encrypted — many apps still send metadata, telemetry, or background sync traffic that reveals information even without breaking the content layer. The attack is cheap (a phone or a $30 travel router is enough) and reliable.
DNS poisoning at the local resolver. The DNS server provided by a public WiFi network is under whoever controls that network’s administration. A malicious or compromised network can point domain lookups at attacker-controlled IP addresses. If your device trusts the network’s DNS server and you navigate to a site whose HSTS policy hasn’t been cached by your browser, you can be redirected to a convincing clone. Even where HTTPS prevents content interception, DNS-level responses reveal your browsing destinations before any encrypted connection is established — your device asks “where is example.com?” over plain text, and a poisoned resolver answers with whatever it wants.
Metadata fingerprinting and traffic correlation. This is the most underestimated risk on the list, and the one that HTTPS-everywhere did least to address. Even on an encrypted connection, a passive observer on the network can see: which DNS names your device is querying (unless you’re using encrypted DNS), which IP addresses you’re connecting to, the timing and size of your connections, and patterns in your traffic that correlate with specific applications or behaviors. Streaming a video looks different from loading a web page. A VoIP call has a distinct timing signature. The sites you visit can be inferred from the IP addresses even without reading the content. None of this requires intercepting HTTPS; it requires sitting on the network and watching what your device does.
The shift in the threat picture is this: in 2010, the risk was your content being read. In 2026, the risk is your activity being observed — who you connect to, when, how often, and for how long.
A 5-minute checklist anyone can follow
None of these require technical knowledge. They’re operational habits.
1. Use a known, signed network. A network with WPA2 or WPA3 authentication is meaningfully harder to attack passively than an open network. If a venue offers both “VenueName” (open) and “VenueName-Secure” (WPA2), use the secured one. An open network with no authentication lets anyone capture packets without even joining.
2. Forget public networks after use. iOS, Android, macOS, and Windows all let you forget a saved network. Do it before you leave. Your device will not auto-rejoin a network with that name in the future — which means it won’t silently connect to an evil twin the next time you’re in the area.
3. Use encrypted DNS. DNS-over-HTTPS is built into most modern browsers under Privacy or Security settings. System-wide options include configuring a trusted resolver like Cloudflare (1.1.1.1) or Quad9 (9.9.9.9) at the OS level. This prevents the network’s DNS server from seeing or manipulating your lookups.
4. Verify the captive portal before entering anything. Legitimate captive portals ask for a room number or a tap to agree to terms — they do not ask for your email password, your payment card, or anything beyond what’s needed to grant network access. If a portal is asking for anything sensitive, close it. Use the venue’s physical staff to get WiFi credentials directly if needed.
5. Turn off file sharing and peer discovery. AirDrop, Windows Network Discovery, Nearby Share — these broadcast your device’s presence and accept incoming connections. On a public network, that surface area is unnecessary. Turn them off before connecting and turn them back on when you’re somewhere you trust.
6. Use a VPN for the network-metadata layer. A VPN doesn’t replace HTTPS — it operates at a different layer. Where HTTPS protects the content of your connections, a VPN wraps your entire network activity in an encrypted tunnel, hiding the metadata: which DNS names you’re querying, which IP addresses you’re connecting to, the volume and timing of your traffic. This is where a VPN actually adds something that HTTPS doesn’t. ORION/VPN’s free 10 GB/month plan is built for exactly this case — light daily use on public networks, no card required. For background on what a VPN tunnel actually does, that article has the mechanics.
7. Keep your device updated. The majority of practical public-WiFi attacks that go beyond passive observation rely on chaining a network-layer entry point with an unpatched software vulnerability. The network gets them adjacent; the unpatched browser or OS gives them leverage. Keeping your device updated removes the second link in that chain.
Where a VPN actually helps — and where it doesn’t
The honest version of this matters, because overstating what a VPN does is exactly how you end up with users who think they’re protected when they’re not.
Where a VPN helps on public WiFi:
Network-level metadata leakage is the clearest win. A VPN tunnels your traffic to a server you control, so the coffee-shop network sees one encrypted connection to a VPN endpoint — not a fingerprint of every app and service your device is talking to. DNS poisoning at the local resolver is also addressed: if your VPN handles DNS (as most do), your lookups go through the tunnel rather than through the compromised local DNS server. Any legacy unencrypted traffic — background app telemetry, older IoT devices, captive-portal HTTP redirects before your browser can enforce HTTPS — gets wrapped in the tunnel and hidden from the network.
Rogue access points are partially addressed: once you’ve joined an evil twin, the attacker is still in a position to intercept your initial connection attempt before the VPN connects. This is the timing gap problem, which always-on mode closes (more on that in the next section).
Where a VPN doesn’t help:
Certificate pinning bypass attacks happen at the application layer, not the network layer. If an attacker has somehow convinced your device to trust a fraudulent certificate authority, the VPN doesn’t know that — it just tunnels the compromised connection. This attack requires compromising the device itself, not just the network, and is well outside the public-WiFi threat model for most users.
Endpoint malware is similarly out of scope. If your device is already infected, traffic leaving the VPN endpoint may be clean while the malware exfiltrates data through a separate channel or operates locally. A VPN secures the network transit. It doesn’t inspect or protect what’s happening on the device.
Account takeover after login is not addressed by a VPN. If you log into a service and that service’s session management is compromised, or you were phished into entering credentials on a fake portal before the VPN connected, the VPN has no role in recovering from that.
The accurate framing: a VPN is a layer of defense for the network layer specifically. It addresses network-level metadata leakage better than any other single control. It is not a substitute for HTTPS, not a substitute for endpoint security, and not a magic shield for your accounts.
Always-on mode — what it closes
Modern VPN clients support always-on mode, sometimes paired with a kill switch: if the VPN connection drops, the network interface is held until the VPN reconnects, rather than falling back to the unprotected network.
The failure mode this addresses is subtle and common. You join an airport WiFi network. Your VPN app is configured to autoconnect — but there’s a 3-second gap between joining the network and the VPN establishing its tunnel. During those 3 seconds, your email client checks for new mail, your calendar syncs, your browser prefetches tabs. All of that happens over the unprotected network, potentially through the evil twin or the poisoned resolver. None of it is catastrophic on its own — but it’s exactly the metadata-leakage surface that public WiFi exposes.
Always-on mode eliminates the gap. The device waits. Nothing transits until the tunnel is up.
ORION/VPN’s macOS client supports always-on with kill switch on the free plan. It’s not a premium feature — it’s on by default for the use case the free plan is designed for, which is exactly public WiFi on devices that auto-connect to known networks.
Closing
Public WiFi isn’t dangerous the way it was in 2010 — it’s dangerous in different, subtler ways. The content of your HTTPS connections is well-protected. Your network activity pattern, DNS queries, and metadata are not. ORION/VPN’s free 10 GB/month plan addresses the remaining surface: always-on mode to close the timing gap, Horizon for networks that filter traffic, Wind for open networks where throughput matters. For a broader look at what a VPN actually does, or the framework for evaluating any free VPN you’re considering, both articles start from the same premise: accurate threat models produce better decisions than dramatic ones.