Public Wi-Fi Risks (Even With HTTPS Everywhere)

A few years ago, the advice for using a coffee shop network was simple and grim: assume someone is reading your traffic. Then HTTPS became the default almost everywhere, browsers started shouting about plaintext sites, and a lot of people quietly stopped worrying.

That second part is the problem. Public wifi risks didn't disappear when HTTPS won — they shifted. The passive eavesdropper who used to sniff your Gmail password off the air has mostly been priced out. What remains is more interesting, more targeted, and harder to notice because the lock icon makes everything look fine.

This post walks through what HTTPS actually fixed, what it didn't, and the handful of habits that meaningfully change your exposure on networks you don't own.

What HTTPS Actually Solved

Credit where it's due. HTTPS — the encrypted version of the web protocol — did fix the biggest, dumbest version of the public Wi-Fi problem.

In 2014, someone on the same airport network as you could run a free tool, watch your browser load Facebook, and walk away with your session cookie. That class of attack is mostly dead. The combination of HTTPS-by-default, HSTS (a flag that tells browsers “never load this site over plain HTTP again”), and tighter cookie rules means casual passive sniffing of mainstream sites doesn't return much.

If your threat model is “I don't want a bored teenager three tables over reading my email,” HTTPS got you there.

The threat model one notch up is where it gets more honest.

What HTTPS Does Not Cover

HTTPS encrypts the contents of your connection to a specific server. It doesn't protect the steps before that connection is established, and it doesn't protect you from yourself when something looks slightly off. Here's where public wifi risks still live.

Captive Portal Injection

The “agree to our terms” page that pops up on hotel and airport Wi-Fi is called a captive portal. To make it work, the network has to intercept your first web request and redirect it somewhere of its choosing. That's a man-in-the-middle by design. Sanctioned, but still a man-in-the-middle.

A well-run captive portal is harmless. A badly run one (or a deliberately hostile one) can serve you JavaScript, push fake software updates, or quietly profile every device that joins. Your phone often shows the portal in a stripped-down browser without the full address bar, which makes it harder to tell what you're actually looking at.

DNS Hijack on Weak Resolvers

When you type bank.com, your device asks the network's DNS resolver “what's the IP address for that?” On a public network, that resolver is run by whoever owns the access point.

A misconfigured or malicious resolver can lie. It can send you to a server that isn't your bank, then present its own certificate. Modern browsers will warn you — but only if the certificate is wrong, and only if you read the warning instead of clicking through.

SSL Stripping on Misconfigured Sites

SSL stripping is an old trick that still works in narrow cases. The attacker sits between you and the site you're trying to reach. You type example.com (no https:// prefix), the network intercepts it, fetches the real HTTPS page itself, and serves you a plain HTTP copy.

Sites that use HSTS preloading are immune. Sites that don't (typically smaller services, internal tools, or anything you reach via an old bookmark) aren't. The address bar will quietly show http:// instead of the lock icon, and most people don't look.

Rogue Access Points and Evil Twins

This is the one worth understanding properly, because it bypasses most of the defenses above.

Your phone remembers networks. When it sees a beacon (a small broadcast packet announcing a Wi-Fi name) that matches one it's joined before, it can connect automatically. An attacker with off-the-shelf hardware can broadcast a beacon claiming to be Starbucks WiFi or Hotel Guest, send a deauthentication frame to knock your phone off the legitimate network, and watch your device hop over to theirs without you touching anything.

From there, the attacker is the network. They control DNS. They run the captive portal. They see which apps on your device are trying to reach which servers, even if the contents are encrypted. They can serve their own captive portal pages, try SSL stripping on anything not preloaded, and prompt for credentials inside what looks like a normal login flow.

The technical name is an “evil twin,” and the quiet part is that nothing warns you it's happening. Your phone just shows the familiar Wi-Fi icon.

Certificate Warning Conditioning

Browsers got good at warnings. Users got good at ignoring them.

When you see a full-page red certificate warning, it almost always means something is wrong with the connection. Sometimes benignly (an expired cert), sometimes not (an active man-in-the-middle). The fix is to not click through. In practice, people have been trained by years of badly configured corporate networks to mash the “proceed anyway” button without reading.

On a coffee shop network, that button can be the entire attack.

How an Evil-Twin Attack Actually Works

If you want one substantive picture of how this fits together, the evil-twin attack is the cleanest example.

The attacker brings a laptop or a small portable device into a coffee shop. They run a piece of software that does three things in sequence.

First, it scans the air for nearby Wi-Fi networks and notes the name (the SSID) of the legitimate one. Say it's Cafe Guest. It then starts broadcasting its own beacon frames with the same name, often at higher power so devices prefer it.

Second, it sends deauthentication frames to clients already connected to the real network. Deauth frames are a normal part of how Wi-Fi works — they tell a device “you've been disconnected, please rejoin.” On most networks they're unauthenticated, which means anyone can send them. Phones on the real network get bumped off and look for somewhere to reconnect.

Third, the attacker presents a captive portal. It might ask for an email and a password “to access free Wi-Fi.” It might mimic the hotel's login page. It might just let you through silently, route your traffic out through their own connection, and log everything. From your phone's perspective, you're online. From the attacker's perspective, they're now your ISP.

The defense isn't to read packet headers. It's to make the attack uninteresting — by not auto-joining unknown networks, by routing your sensitive traffic through something the local network can't see into, and by not entering credentials into pages you didn't navigate to deliberately.

Is Public Wi-Fi Safe in 2026?

Honest answer: safe enough for most things, not safe enough for everything.

Reading the news, looking up a recipe, scrolling social — fine. The cost of getting that traffic wrong is low and the protections in modern browsers are real.

Logging into your bank, accessing a work admin panel, approving a wire transfer, or signing into a new service that texts you a recovery code — these are higher-value moments where the gap between “probably fine” and “definitely fine” matters. The cheap answer to closing that gap is to not do them on networks you don't control.

Five Practical Steps

None of these require thinking about packet frames. They're habits.

1. Turn off auto-join for unknown networks. On iPhone, this is under Settings → Wi-Fi → Auto-Join Hotspot, and per-network under Wi-Fi → (network name) → Auto-Join. The point is to make your device ask you before it joins something with a familiar name. See our iPhone VPN setup walkthrough for related steps.
2. Prefer cellular or your own hotspot when possible. A 5G connection isn't perfectly private, but it has a single, accountable operator, and there's no easy way for a stranger to insert themselves into the middle of it. For anything sensitive while traveling, your phone's hotspot is usually a better answer than the hotel network.
3. Use a VPN for the moments that matter. A VPN, short for virtual private network, routes your traffic through an encrypted tunnel to a server you trust, so the local network sees only that one connection and nothing about where it's going. This neutralizes most of the categories above: the captive portal can still nag you, but it can't see your DNS lookups, can't strip SSL on the sites you visit, and can't profile which apps you're using. If you're new to the idea, our primer on what a VPN actually is covers the basics, and our guide to VPNs on the road gets into the specifics. Snap is one option built around that posture, but the broader habit matters more than the brand.
4. Never click through certificate warnings on public networks. If you see a full-page browser warning about a certificate, close the tab. On your home network it's almost always a misconfigured site; on coffee shop Wi-Fi it might be someone actively in the middle. The cost of being wrong is high enough that “try again later” is the correct default.
5. Save sensitive logins and transactions for trusted networks. Banking, password resets, anything involving a recovery code or two-factor flow — these are worth the small friction of waiting until you're back on cellular or home Wi-Fi. The convenience gain from doing them at the airport isn't worth the asymmetry of what can go wrong.

What a VPN Does and Doesn't Fix

There's a lot of noise on this point, so worth being specific.

A VPN does fix:

• The local network's ability to see your DNS lookups
• SSL stripping (your traffic doesn't traverse the hostile network in cleartext)
• Captive portal profiling after you've passed the captive portal
• A rogue access point's ability to learn anything useful about your activity

A VPN does not fix:

• A certificate warning you click through anyway
• Phishing pages you actively log into
• Malware already on your device
• The fact that the websites you visit can still identify you through accounts and cookies

It's a sharp tool for one specific class of public wifi risks. It's not a magic shield, and products that sell it as one are overselling what it does. Our roundup of common VPN myths gets into more of the marketing-versus-reality gap.

Bottom Line

HTTPS solved the easy version of the problem. The harder version, the layer beneath the connection where DNS, captive portals, and rogue access points live, is mostly invisible until something goes wrong.

You don't need to become a network engineer to be reasonable about this. Turn off auto-join, be skeptical of captive portals, don't click through certificate warnings, and use cellular or a VPN when the stakes are real.

If you'd like the VPN part handled cleanly on iOS — no email at signup, no traffic logs, subscription billed quietly through your Apple ID — Snap is built around exactly that posture. macOS is on the way. Either way, the most important thing isn't which app you install; it's that you stop treating the coffee shop network like it's your own.