The short version: the classic 2015-era "someone on the coffee-shop WiFi can read your passwords" threat is mostly dead — HTTPS is everywhere, HSTS preload covers the big sites, and SSL strip attacks have a much smaller surface than they used to. But three categories of attack still work in 2026, and the attackers have adapted: evil-twin rogue APs (recreate a network you trust and let your device auto-join), captive portal exploitation (the splash page that takes your email or pushes malware), and traffic analysis at the metadata layer (encrypted-but-observable: who you're talking to, when, how often, how much). The interventions that materially help are: a real VPN tunnel (not just DNS), MAC randomization left on, ignoring unsolicited captive-portal credential prompts, and the security defaults Apple/Google ship by default.
What's actually happening on a typical hostile network
A "hostile network" doesn't necessarily mean the coffee shop is evil. It usually means one or more of:
- The legitimate network operator is collecting data on connected devices (extremely common at retail, somewhat common at hotels) for marketing or analytics.
- Another patron is running observation tools on the same subnet (less common than it used to be, but trivial with $200 hardware).
- An attacker is running a rogue access point nearby with the same SSID as a trusted network, hoping your device auto-joins.
- The captive portal serves malicious content — either ad injection (annoying), credential phishing (harmful), or malware push (rare but high-impact).
For most people, on most days, none of these meaningfully matter — HTTPS encryption protects your active sessions, and modern OS defaults handle the obvious cases. The cases that still matter are when you're on a network long enough for the patient attacker to wait you out, or when you blindly accept a captive portal's request, or when your device auto-joins what you think is your home network but isn't.
Attack 1 — Evil twin (rogue access points)
What it is: An attacker brings a portable access point (a WiFi Pineapple, or just a laptop with the right software) into range of a target. They broadcast an SSID that matches a network the target's devices have connected to before — "attwifi", "xfinitywifi", "Starbucks WiFi", your home network's name — and a stronger signal than the legitimate one (or the legitimate one isn't in range at all).
Your device, sitting in your pocket, auto-joins because it sees a "known" SSID. Now the attacker is the network: they see your DNS queries (and your unencrypted traffic, though there's not much of that left), they can run captive portal prompts, and they can attempt other downstream attacks.
2026 reality: still works, with adaptations. iOS 14+ and Android 10+ both implement Private MAC Address — your device presents a different MAC to each SSID, so cross-network tracking is harder. But that doesn't stop the auto-join behavior; the attacker doesn't need your real MAC, they just need your device to associate. What's helped more is that iOS 16+ explicitly warns about networks with poor security (open, WEP, WPA-only) and increasingly nudges users away from auto-joining; Android 13+ does similar.
What stops it: Turn off "auto-join" for public networks (Settings → Wi-Fi → tap network → Auto-Join Off on iOS; same path on Android with slight UI differences). On networks you do join, a VPN tunnel means the attacker-as-network only sees encrypted bytes — they can't read your traffic, can't inject content, can't run captive-portal credential phishing successfully (because your browser will warn about cert mismatches if they try).
Attack 2 — Captive portal exploitation
What it is: The splash page that appears when you join WiFi at a hotel, airport, or coffee shop ("Accept terms to continue"). The portal page is served by the network's authentication system and is, by design, the first thing your device sees on that network — before your VPN can establish, before HTTPS warnings have context, before you're really sure who's serving it.
Three variants of how this is exploited:
- Credential harvesting: the splash page asks for your email and a password "to authenticate." Many people enter the password they use for other accounts. The attacker now has email + password from your typical reuse pattern.
- Drive-by malware push: the splash page links to "your free coffee voucher" which is a malicious app download. Most modern browsers warn; mobile users tap through warnings more than desktop users do.
- Personal-data collection: the splash page asks for your phone number "for connectivity" and you give it. Now it's in a marketing database, often resold.
2026 reality: captive portal phishing has gotten more common, not less. The OS-level protections (private MAC, VPN) don't help here because the user is willingly entering data. What's helped is iOS 17+ and Android 14+ presenting captive portals in a sandboxed mini-browser that limits exfiltration paths — but the data the user types in still gets sent.
What stops it: Never enter a password you use elsewhere into a captive portal. Never enter a phone number that you use for anything important. Treat captive portals as adversarial by default. If a network requires "registration" that asks for substantive info, leave it and use cellular for the next hour. Casper's AI threat detection scores captive-portal domains the same way it scores SMS phishing — known-bad portals are flagged before you type anything.
Attack 3 — Traffic analysis at the metadata layer
What it is: Even when your traffic is encrypted (HTTPS, TLS, every modern protocol), an observer on the same network can still see who you're talking to, when, how often, and how much data flows. They can't read the contents, but they can build a profile of your behavior.
On a hostile WiFi network, this means:
- The local operator can see you visit your bank, your healthcare provider, your dating app, etc. — even if they can't see what you do there.
- Patterns of traffic volume reveal what you're doing (video streaming has a distinctive shape; messaging has another; banking has another).
- DNS queries (unless using DoH/DoT/DNS-over-VPN) leak hostname-level destinations.
- TLS Server Name Indication (SNI), historically leaked the destination even when DNS was encrypted — Encrypted Client Hello (ECH) is closing this gap as of 2025-2026.
2026 reality: ECH adoption is meaningful (Cloudflare turned it on by default in late 2024, major browsers support it in stable releases) but coverage is partial. For sites that haven't enabled ECH, SNI still leaks. Even with ECH, the IP-level connection destination is still observable, and IP-to-service mappings are public — connecting to a cluster of IPs owned by Meta tells the observer you used WhatsApp or Instagram, even with everything encrypted.
What stops it: A full VPN tunnel. Your traffic exits the local network destined for one IP (the VPN endpoint); the local network can see you're using a VPN but can't see anything beyond that. This is the single most-impactful protection against traffic analysis on hostile networks. DNS-only protections (NextDNS, Cloudflare 1.1.1.1) help with the DNS-query channel but don't address SNI or IP-level observation — for that you need the tunnel. Our deep-dive on DNS-level filtering limits covers exactly this gap.
Attacks that mostly don't work anymore
Three classic public-WiFi threats that 2015-era guides obsess over but that are largely solved in 2026:
SSL strip / SSL split
sslstrip (Moxie Marlinspike's 2009 tool) downgraded HTTPS to HTTP on the network and rewrote forms — for years a coffee-shop classic. Today: HSTS preload covers virtually every site that handles credentials (banking, email providers, social, etc.). Browsers refuse to downgrade preloaded domains. Sites without HSTS exist but rarely handle anything an attacker would want to read.
ARP spoofing for general MITM
ARP spoofing on a shared subnet lets an attacker insert themselves between your device and the gateway. Still works for the LAN segment, but what they get is encrypted traffic — same problem as the traffic-analysis attack above. The "see your passwords" payoff is gone unless they can also defeat TLS, which they typically can't on preloaded sites.
DNS spoofing on the local network
A hostile network operator can return false DNS answers for hostnames you query, redirecting you to phishing clones. This was effective when DNS was unencrypted and TLS certs were easy to forge. Today: certificate transparency logs and HSTS preload mean the phishing clone would have to obtain a valid cert for the target domain (extremely hard for popular sites) — and DNS-over-HTTPS / DNS-over-TLS / VPN-routed DNS each defeat the spoofing at the DNS layer. Still works for unsavvy users on small obscure sites; rarely an issue for the average consumer.
Per-platform defaults: what each OS does for you
iOS / iPadOS
- Private MAC Address on by default for new SSIDs since iOS 14
- Warnings for WPA2-and-below networks (push toward WPA3) since iOS 16
- Auto-join behavior controllable per-SSID
- iCloud Private Relay (iCloud+ subscribers) encrypts Safari traffic — see our Private Relay deep-dive for what it covers and doesn't
- VPN-on-Demand support for triggering Casper automatically when on untrusted SSIDs
Android
- Private MAC Address (called "Use randomized MAC") on by default since Android 10
- Private DNS (DoT) native support since Android 9
- Per-app VPN routing (more flexible than iOS)
- "Verify saved networks" alerts since Android 13 — flags when a known SSID has a different security profile than before (potential evil twin)
- Network-level threat detection in Play Protect
macOS
- Private Wi-Fi Address since macOS Sequoia (parity with iOS)
- iCloud Private Relay (iCloud+)
- Built-in firewall + Stealth Mode (off by default — see our macOS privacy guide)
- FileVault encryption (defaults on for new Macs)
Practical workflow: what to actually do when you connect to coffee-shop WiFi
- Verify the SSID with the establishment. "What's your WiFi name?" — a 3-second check that defeats most evil-twin attacks. The fake AP usually has a name that's a near-match for the legitimate one but not exact.
- Accept the captive portal without entering substantive data. "Accept terms" — fine. "Enter your email + password" — close the tab, use cellular. "Enter your phone number" — only if you trust that data not getting sold.
- Turn on your VPN before doing anything sensitive. Some setups (Casper's iOS app, NetworkExtension auto-trigger) do this automatically when joining new SSIDs. The window between joining the network and the VPN connecting is when traffic-analysis attacks are most exposed; minimize it.
- Don't auto-join the network for future visits unless you trust the operator. The 5-second cost of manually joining each time is worth the 0.01% probability of an evil-twin attack at that location later.
- Disable Bluetooth / AirDrop if you don't need them on truly hostile networks. These are separate threat surfaces from WiFi but are often co-attacked.
- Forget the network when you leave. Settings → Wi-Fi → tap network → Forget. Reduces future-auto-join exposure.
When is a VPN actually necessary vs nice-to-have?
Honestly: on a typical 5-minute coffee-shop visit doing email + Slack on HTTPS-everywhere services, the practical threat is low. The TLS protections are doing the work. A VPN provides defense-in-depth, but you're not getting visibly attacked without one most of the time.
The cases where a VPN materially matters:
- Hostile international networks (hotel WiFi abroad in jurisdictions with active state-level surveillance, or known-hostile conference networks).
- Long sessions on the same network (working from a coffee shop for hours, hotel WiFi for a multi-day stay) — gives attackers time and stationary target.
- Networks of unknown provenance (the WiFi at someone's small office, the network at a small Airbnb, conference WiFi run by who-knows).
- When sensitive activities matter — accessing healthcare info, doing actual banking, anything you'd be unhappy about an observer profiling.
- To defeat traffic-analysis profiling by the network operator, who's almost always logging at least metadata.
For these cases, a real VPN tunnel (not just DNS-level filtering) is the right intervention. Casper's threat-protection layer bundles the WireGuard tunnel with AI-based zero-day phishing detection, blocklist filtering, and per-app routing controls. The tunnel is on; the encryption is end-to-end; the local network sees encrypted bytes and nothing else.
What about phone hotspot vs public WiFi?
Your phone's hotspot (cellular tethering) is dramatically safer than random public WiFi because:
- You're the only device on it (no other patrons running observation tools)
- The carrier is the only upstream operator (a known entity, regulated, generally trustworthy at metadata level)
- The encryption is your phone's WPA3 setup which you control
- It's transient — no ongoing exposure when you move
The cost is data usage. For privacy-sensitive sessions (banking, healthcare, sensitive work) tethering is generally a better default than hotel/coffee-shop WiFi — especially if you don't have a VPN configured. Most carriers include some hotspot data in modern plans; check before relying on it for long sessions.
Bottom line
Public WiFi in 2026 isn't the 2015 disaster zone, and the standard advice ("never use public WiFi") is increasingly out of touch with the actual threat model. The pragmatic 2026 framing: HTTPS protects the contents of your traffic; what remains exposed is the metadata, the captive portal, and the auto-join attack surface. A VPN closes the metadata and traffic-analysis gap. Captive-portal discipline (don't type passwords or emails into them) closes the phishing gap. SSID verification before joining handles the evil-twin case.
If you want all of that automated — VPN on, threat detection on, DNS filtering on, per-app routing where you want it — that's what Casper does on every network you join. Free trial, apps for iPhone, Mac, and Android.