Public Wi‑Fi safety: on-path risks, HTTPS limits, and VPN trade-offs

Why guest Wi‑Fi is different from home

Captive-portal hotspots in hotels, airports, and cafés are optimized for easy attachment, not mutual authentication. Unless the network uses WPA3-Enterprise or you add your own layer of trust (for example 802.1X to an employer SSID), other stations on the same broadcast domain can attempt ARP/cache manipulation, rogue DHCP/DNS, and SSID impersonation. Convenience is real; so is the enlarged attack surface.

This article stays vendor-neutral: it explains what observers can infer, where HTTPS and Private DNS help, and why many teams default to cellular or split-tunnel VPN for sensitive workflows. It is not a substitute for your organization's acceptable-use policy.

Common attack patterns on shared WLANs

Defenders prioritize understanding mechanisms, not personalities. Many demonstrations use commodity hardware and widely documented tools because 802.11 frames are observable by design within the same BSS unless additional controls (client isolation, private VLANs, WPA3) are enforced by the operator—controls you cannot assume on random guest SSIDs.

1. Rogue access point (evil twin)

An attacker advertises an SSID that resembles the venue network. If your device attaches, the attacker becomes the default router and can attempt DNS redirection, TLS stripping (where cleartext is still possible), and captive-portal phishing. Client isolation reduces impact but is not universal; treat unknown SSIDs as untrusted.

2. Passive capture and session replay

Wireless frames are broadcast to the BSS. Tools such as Wireshark can record cleartext protocols or metadata. Modern sites should pin sessions to HTTPS, but historical session sidejacking against cookie-based auth over HTTP illustrates why transport encryption and Secure cookie flags matter. Prefer apps that certificate-pin or use OAuth device flows where appropriate.

3. Captive-portal and installer social engineering

Hotspots often show login pages that could be cloned. Decline unsolicited downloads; verify OS updates only through vendor channels. A VPN does not replace endpoint hygiene—malware still executes if you approve it.

VPNs and other transport mitigations

802.11 link-layer controls that complement VPN transport

VPNs protect IP payloads above the tunnel; Wi‑Fi security protects the L2 association. WPA3-Personal improves handshake resistance versus WPA2; WPA3-Enterprise uses 802.1X/EAP (often EAP-TLS or TEAP) for per-user keys in corporate SSIDs. 802.11w (Management Frame Protection) reduces trivial deauth abuse on capable networks.

On open hotspots, even with a VPN, an attacker can still attempt captive-portal phishing or DHCP option injection—treat association policy as separate from tunnel encryption. Prefer cellular or known SSIDs for high-value authentication.

A VPN relocates your egress IP and wraps many protocols in an encrypted tunnel to a provider you choose—shifting trust from the café AP to that provider. It can hide DNS and traffic patterns from the local operator, but it does not magically authenticate the hotspot. Combine VPN use with split tunneling policies for enterprise SaaS, kill switches to block plaintext during reconnects, and provider selection criteria aligned to logging and jurisdiction requirements.

Modern VPNs typically use AEAD ciphers such as AES-GCM or ChaCha20-Poly1305; security depends on key management and software quality, not marketing adjectives alone.

Comparing Your Defenses

Security Level	Method	Protection Level	What a local observer often sees
Open Wi‑Fi only	Open Wi-Fi (No VPN)	Zero	Every site, cookie, and unencrypted password.
HTTPS only	HTTPS (Browser Padlock)	Moderate	The site you're visiting (via DNS), but not the page content.
Wi‑Fi + VPN	Public Wi-Fi + VPN	High	A scrambled, encrypted tunnel of random data.
Cellular (4G/5G)	Cellular Data (4G/5G)	Highest	Nothing (Point-to-point encrypted connection).

HTTPS alone does not hide all metadata

Many people think, "The sites I visit have the padlock (HTTPS), so I'm safe on public Wi-Fi!" This is only partially true. While HTTPS encrypts the content of the page, it leaves two major leaks:

DNS privacy: Name resolution must occur somewhere. Without DoH/DoT or a resolver reached only through a trusted tunnel, local observers may read queries and infer destinations even when HTTP content is encrypted. See Private DNS for transport options.
SNI and TLS metadata: Depending on client, server, and middlebox behavior, hostname signals may still appear in Client Hello or enterprise inspection paths. Encrypted Client Hello (ECH) and careful resolver placement reduce—but rarely eliminate—metadata exposure on hostile LANs.

A VPN can tunnel DNS to a resolver you trust; it is one mitigation among several—not invisibility against every correlation technique.

The 'Field Guide' Rules for Wireless Safety

Disable 'Auto-Join': Go into your phone and computer settings and turn off "Connect to Open Networks Automatically." This prevents your phone from joining an unintended rogue SSID while it's in your pocket.
Set Network to 'Public': When Windows asks if a new network is 'Private' or 'Public', always choose Public. This turns off file-sharing and printer-discovery, effectively putting up a wall around your device.
Enable a Kill Switch: Ensure your VPN has a 'Kill Switch' feature enabled. If your Wi-Fi signal drops for a second and then reconnects, the Kill Switch stops all data movement until the VPN tunnel is re-established. Without it, your device might leak data in that split-second gap.
Use 2FA (Two-Factor Authentication): Even if an attacker captures a reusable password, 2FA will stop them from logging in because they don't have the code on your phone.
Forget the Network: After you leave the airport or cafe, 'Forget' the network in your settings. This prevents your device from broadcasting a signal later that says "Hey, is 'Airport_Free_Wifi' around here?" — a probe request attackers may abuse for automatic association into connecting to a fake network in the future.

Pro Tips for Travelers

Carry a Travel Router: If you travel a lot, buy a small 'GL.iNet' travel router. You connect it to the hotel Wi-Fi, it runs the VPN at the hardware level, and then creates your own private, encrypted Wi-Fi network for your laptop, phone, and tablet to join.
DNS over HTTPS (DoH): If you absolutely cannot use a VPN, go into your Chrome or Firefox settings and enable 'Secure DNS'. This encrypts your website lookups (DNS) so the local cafe owner can't see your browsing history.
Check Your IP Status: Before doing anything sensitive, confirm egress using your public IP context. If the ISP and geolocation align with the VPN POP and not the local cafe, you know your tunnel is active and secure.

Guest Wi‑Fi remains useful when risks are scoped: keep high-value authentication on cellular or hardened tunnels, verify SSIDs with staff when unsure, and review OS network profiles. For DNS and SNI considerations, pair this guide with how DNS works and your public IP baseline.

Only partially. HTTPS encrypts the content of your communication with a website, but your DNS lookups and initial connection requests are often leaked in plain text. An attacker can still see which websites you are visiting even if they can't see your specific messages.

Not really. If everyone in the hotel has the same password, the network is still 'open' to anyone in the building. An attacker can use ARP spoofing to trick your device into sending data to them instead of the router.

It is a fake Wi-Fi network set up by a attacker that mimics a real one (like 'Starbucks_Guest'). When you connect, you are actually routing all your internet traffic through the attacker's device.

While a VPN makes it significantly safer, most security experts still recommend using your cellular data (LTE/5G) for banking while traveling. Cellular networks are architecturally much harder to intercept than Wi-Fi.

A Kill Switch is a security feature that immediately cuts your internet connection if the VPN tunnel drops. This prevents your device from accidentally sending unencrypted data over the public Wi-Fi during a connection glitch.

Yes. The owner of the Wi-Fi (the cafe or hotel) will only see an encrypted stream of data going to a VPN server. They cannot see the names of the websites you are visiting or the apps you are using.

No, most public Wi-Fi is legitimate. However, it is fundamentally insecure. Even a 'safe' network can have a malicious actor sitting on it waiting for unencrypted traffic.

Yes, absolutely. On Windows and macOS, ensure your network profile is set to 'Public'. This disables features that would allow others on the same network to see your shared folders or printers.

Only if you have remote desktop features enabled or if you've accidentally installed malware. Simply being on the same Wi-Fi does not give someone access to see your actual screen.

Apple's iCloud Private Relay works similarly for Safari traffic, but it doesn't protect other apps as comprehensively as a system-wide VPN does.

To prevent your device from automatically connecting to it in the future. attackers can use 'Pineapple' devices to listen for your phone's request for an old network and then 'spoof' that network to trick your phone into an automatic connection.

It is the process of using software (like Wireshark) to capture and analyze data as it travels through the airwaves. On open networks, this data is often unencrypted and easy to read.

A VPN protects your privacy and data in transit, but it doesn't usually stop you from downloading a malicious file. You still need an antivirus and common sense.

Many free VPNs sell your data to advertisers or have weak encryption. It is almost always better to pay for a reputable service or use a trusted free tier like ProtonVPN.

Only if you have a VPN active. Without it, your email login cookies could be stolen, giving a attacker access to your entire inbox without your password.