"All your data is stolen on public WiFi" β that was true in 2010, when most traffic was unencrypted HTTP. Today ~95% of web traffic is HTTPS, and the catastrophic packet-sniffing attacks (Firesheep, anyone?) mostly don't work. But "public WiFi is safe now" is also wrong. The remaining risks are real, just different from what you might expect.
What used to be dangerous
In the late 2000s and early 2010s, the canonical public-WiFi attack was simple: open packet capture (Wireshark or a Firesheep-style tool) on a coffee-shop network, and read everything that wasn't HTTPS. Most websites at the time used HTTPS only for login pages and sent everything else in plain text β including session cookies. An attacker could grab a Facebook session cookie from someone on the same WiFi and impersonate them within minutes.
This attack effectively no longer works on the modern web. The HTTPS migration (driven by Let's Encrypt, browser warnings about HTTP, and the SEO ranking boost Google gave HTTPS sites) was largely complete by 2018. Email, banking, social media, and almost all major sites are HTTPS-only.
What's actually dangerous now
1. Metadata exposure (SNI + DNS + IP)
Even with HTTPS, your traffic leaks metadata in plaintext:
- SNI: the TLS handshake includes the hostname you're connecting to. An attacker on the WiFi can see "you connected to bankofamerica.com" even though they can't see the page contents.
- DNS queries: if you're using the WiFi's DNS resolver (default), every domain you query is visible in plaintext to whoever runs that resolver.
- Destination IPs: visible in packet headers. Less precise than SNI but still indicative.
Result: an observer learns which sites you visit, when, and how much data flows. They don't learn what you do on those sites β but the metadata alone is often enough.
2. Evil twin access points
An attacker creates a fake AP with the same SSID as the legitimate one (e.g., "Starbucks_Free" or "HotelWiFi") and waits for devices to auto-connect. Devices generally prefer stronger signals, so an attacker physically close to the target can win the race.
Once you're on the fake AP, the attacker controls:
- DNS responses (can redirect you to phishing sites).
- Captive portal (can present fake login pages to harvest credentials).
- Plaintext traffic (any non-HTTPS connections).
- SSL stripping attempts (forcing HTTP downgrades on sites that don't enforce HSTS).
Evil twin attacks are more common at airports, hotels, and conferences than at random coffee shops, but they're not rare.
3. Captive portal manipulation
The "click to accept terms" page on hotel WiFi works by intercepting HTTP traffic and redirecting it to the login page. The technology is benign per se, but it relies on plaintext HTTP being interceptable.
A malicious operator can:
- Inject JavaScript or ads into the captive portal page (some hotels and ISPs have done this commercially).
- Present a fake login page that harvests credentials.
- Use the captive portal redirect to fingerprint your device.
You can't avoid the captive portal β you need it to get internet β but the security exposure is bounded to the portal interaction.
4. SSL stripping (mostly mitigated)
SSL stripping attempts to downgrade your HTTPS connection to HTTP by intercepting the initial redirect. Modern browsers and HSTS (HTTP Strict Transport Security) protect against this for most major sites. But sites without HSTS, or first-visit connections to new sites, can still be stripped.
5. Network discovery and lateral attacks
Once you're on a WiFi network, your device may be discoverable to other devices on that network β depending on AP configuration. If client isolation isn't enabled, other devices can:
- Scan for open ports on your device.
- Attempt to exploit known vulnerabilities.
- Probe shared services (network printers, file sharing, AirDrop, etc.).
Modern OS defaults make most of these attacks fail (no open file shares, firewalls block ports by default), but devices with old firmware or unusual configurations are more vulnerable.
What a VPN does about all this
| Threat | HTTPS alone | HTTPS + VPN |
|---|---|---|
| Plaintext sniffing | Protected | Protected |
| SNI / DNS / IP metadata | Leaks | Encrypted in tunnel |
| Evil twin AP | Partial (HTTPS warns on cert) | Tunnel exits at VPN, not local AP |
| SSL stripping | Mostly protected (HSTS) | Doesn't matter β tunnel is the cert |
| Captive portal abuse | Vulnerable | VPN can't activate until you're past portal β careful |
| Lateral network attacks | Vulnerable | VPN doesn't help (device firewall does) |
Bottom line: a VPN is meaningful protection on public WiFi for the metadata layer and against rogue AP attacks. It's not magic. It doesn't replace device firewalls, OS updates, or sensible behavior (don't enter passwords before the VPN is connected).
Practical guidance
- Connect to the WiFi.
- Get past the captive portal if there is one.
- Immediately connect your VPN before opening anything else.
- Enable kill switch so traffic blocks if the VPN drops.
- Verify with our IP check that the tunnel is active.
- Avoid logging into anything sensitive in the brief window before the VPN is connected (mostly during the captive portal phase).
For step-by-step instructions specific to ClownVPN, see our practical public WiFi guide.