Most home networks put one household behind one router, with every device trusting every other device by default because they're all yours. Hotel, cafe, and conference wifi routes dozens or hundreds of unrelated devices through the same access point, often on the same subnet, frequently without client isolation enabled, because isolation breaks the casting and printing features guests expect to work.
What "same subnet" actually exposes
On a network without client isolation, devices can see each other's presence and, depending on configuration, respond to ARP requests that let another device on the segment quietly reroute your traffic through itself. This is the mechanism behind most "wifi hacking" demonstrations you'll see at security conferences: not breaking encryption, just sitting on the same local segment and asking, politely, in a protocol with no built-in authentication, to be treated as the gateway.
Captive portals compound this. The login page a hotel serves before granting internet access is, from a security standpoint, a piece of unauthenticated infrastructure your device trusts implicitly the moment it joins the network. A malicious actor on the same floor can stand up a nearly identical access point with a stronger signal, a technique generally called an evil twin, and a device set to auto-join known network names will connect to whichever signal is loudest without checking who's actually running it.
What TLS protects, and the part it doesn't
Once you're past the captive portal and on the real internet, HTTPS is doing real work: the content of your traffic to any TLS-protected site is encrypted end to end between your device and that site's server, regardless of who's watching the local network. That part of the picture is genuinely solid and has been for years.
What's still visible to someone on the same network, in most current deployments, is the domain name you're connecting to. The TLS handshake includes a field called Server Name Indication that tells the server which site you want, and by default that field goes out in cleartext before encryption is established. A newer extension, Encrypted Client Hello, closes this gap, but it requires support from both your browser and the site's hosting infrastructure, and as of 2026 that support is still inconsistent across the web. The practical result: someone on the hotel network can't read your banking session, but they can often see that you connected to your bank.
Even with perfect TLS, a passive observer on a shared network can typically see: which domains you visited, roughly how much data you exchanged with each, and the timing pattern of your connections. None of that is your messages or your password. All of it is a usable behavioral fingerprint.
DNS is the other leak
Before your device can connect to anything, it resolves a domain name to an IP address, and by default that DNS query goes out in plaintext to whatever resolver the network's DHCP server handed your device, which on hotel and cafe networks is whatever the property's ISP configured, not one you chose. Every domain you visit gets logged by that resolver whether or not the connection that follows is encrypted. DNS over HTTPS and DNS over TLS close this specific gap by encrypting the query itself, and most modern browsers and operating systems support configuring a resolver manually, though it typically requires a deliberate setting change rather than being the default.
Where a VPN actually helps, and where it just moves the trust
A VPN wraps your entire connection, DNS queries included, in an encrypted tunnel to a server the VPN provider controls, before any of it touches the local network. That genuinely closes the local-network exposure: ARP tricks, evil twins watching your SNI, a curious DNS resolver, all of it becomes invisible to anyone else on the hotel's segment, because your traffic is opaque encrypted noise the moment it leaves your device.
What it doesn't do is make the exposure disappear. It relocates it to the VPN provider, who can now see the same domain and timing metadata the hotel network used to see. That's a real improvement if the local network is the specific threat you're worried about, business travelers on a conference room's wifi, journalists reporting from a hotel abroad, but it's not privacy in the abstract. It's a trade of one observer for a different one, and the VPN provider's jurisdiction, logging policy, and business model all become the relevant questions. We covered that trade-off in more depth in our VPN limitations piece.
| Threat on shared wifi | What handles it |
|---|---|
| Message and password content exposure | TLS, already the default on most sites |
| Which sites you visited (SNI) | Partial: needs Encrypted Client Hello, or a VPN |
| DNS query logging by the local resolver | Encrypted DNS, or a VPN |
| ARP-based traffic redirection on the local segment | A VPN tunnel, since it bypasses the local segment entirely |
| Evil twin access points | Mostly you: verify the network name with staff, disable auto-join |
The practical version
Turn off auto-join for open networks in your device settings, so you're not silently reconnecting to whatever signal is strongest. Confirm the network name with staff rather than trusting the strongest signal in the list. If the connection you care about matters, prefer a VPN over trusting the local network, and pick a provider whose logging policy you've actually read rather than the one that came free with your router. None of this requires new hardware or a security background. It requires treating a hotel's wifi the way you'd treat a hotel's phone line a generation ago: useful, functional, and not yours.