Public Wi-Fi on Android: what leaks before the browser opens

The story you usually hear about public Wi-Fi is “someone in the coffee shop is reading your traffic.” That story has been mostly outdated since the web moved to HTTPS by default. The real story, in our reading, is more mundane and more interesting: by the time you actually open a browser tab, your phone has already had a small but noisy conversation with the access point and the surrounding equipment. This post walks through what is in that conversation, what a VPN actually changes, and what it does not.

The captive-portal moment

You walk into a hotel or an airport and your phone associates with the open Wi-Fi network. Before you tap anything, several things have happened:

• Probe requests. Android’s Wi-Fi stack broadcasts probes asking which of the SSIDs it knows about are available. Modern Android randomizes the MAC address used for probing on a per-SSID basis, but the SSIDs you have associated with in the past are observable to anyone listening on the same channel.
• Association. Once you join, the access point knows the MAC address you are presenting on this network and the manufacturer prefix it derives from. The captive portal logs an association event.
• Background TLS handshakes. Within seconds, push-notification clients (Google’s Firebase Cloud Messaging, iCloud, WhatsApp, and others) reconnect. Each handshake includes a Server Name Indication (SNI) field that names the destination host in the clear, so the network operator can see “this device is talking to fcm.googleapis.com” even if it cannot read the contents of the conversation.
• Captive-portal probes. Android sends a small HTTP request to a known endpoint to detect whether the network is gating internet access behind a portal. The result of that probe drives whether Android pops the “Sign in” notification.

None of this requires you to have opened an app yourself. It is the OS doing what it normally does on a new network.

Background traffic that fires before you tap

After the OS settles, your installed apps wake up:

• Calendar and mail sync. Your calendar provider, your mail client, and any work-account integration retry their pending syncs.
• OS telemetry and update checks. The phone may check for system updates, app updates from the Play Store, and security-policy refreshes for any work profile.
• Anything with a foreground service. If you left a podcast app, a navigation app, or a fitness tracker in a foreground state, it will keep its sockets open across the network change.

Each of these is, individually, fine. Together, they are a sustained beacon to the access point and to any upstream observer that this device (at this MAC, at this point in time) is alive and attached to a particular set of cloud services.

DNS leakage and why HTTPS isn’t enough

Most websites today force HTTPS, which means that someone on the same Wi-Fi cannot read the contents of your browsing. What they can usually still see, even on a fully HTTPS web:

• DNS queries. Unless your phone is using DNS-over-HTTPS or DNS-over-TLS, every domain you look up is a plaintext UDP query to whatever resolver the access point advertised. That is the easiest single source of “what is this person looking at.”
• TLS Server Name Indication. Even when the connection is encrypted, the SNI field in the ClientHello is in the clear unless the ecosystem has rolled out Encrypted Client Hello, which is still partial.
• Destination IPs and traffic shapes. Even if SNI were fully encrypted, the destination IP plus the size and timing of TLS records is enough to tell a streaming session apart from a video call apart from a chat client.

This is the gap a VPN exists to close on untrusted networks.

What a VPN actually fixes

A consumer VPN (TuxlerVPN Mobile included) fixes a specific subset of the above. We try to be precise about what:

• The on-path operator stops seeing your DNS lookups and SNI. With the tunnel up, your DNS queries are sent through the encrypted tunnel to a resolver reached via our gateway, and your TLS handshakes happen inside the same tunnel. The coffee-shop AP and the upstream ISP see opaque UDP packets between your phone and our gateway IP.
• Background-app reconnects ride the tunnel. Your push-notification client and your calendar sync are no different from your browser as far as the OS is concerned. They are all packets, and they all enter the WireGuard tunnel because of the AllowedIPs = 0.0.0.0/0, ::/0 configuration discussed in How WireGuard works on Android.
• The destination service stops seeing your network’s IP. The site you connect to sees the gateway’s IP, not the hotel’s IP.

What a VPN does not fix on public Wi-Fi:

• The gateway becomes a new on-path party. The TuxlerVPN Mobile gateway sees your TLS SNI and destination IP for the duration of the connection. That is fundamental to how a VPN works. What we do with that visibility is governed by Logging & Retention Data. Session metadata is discarded on disconnect.
• TLS certificate trust stays as it is. A VPN does not change the set of root CAs your phone trusts. If you have ever installed a custom certificate (work device, parental-controls product), that CA can still terminate TLS for you regardless of whether a VPN is on.
• Probe requests on Wi-Fi join. The Wi-Fi association itself happens before any VPN can be active. The VPN starts encrypting after you have a network. Use Android’s “MAC randomization” setting on a per-network basis to limit what an AP can correlate across visits.

What our setup does about reconnects and DNS

Two specifics worth being explicit about:

• DNS is pushed into the tunnel. When the app constructs the virtual interface via Android’s VpnService.Builder, it calls addDnsServer(...) for each resolver in the WireGuard config’s [Interface] DNS = ... line. The OS then routes DNS through the virtual interface, which means it travels inside the encrypted tunnel.
• Cleartext HTTP from the app is blocked at the platform level. The app’s network_security_config.xml sets cleartextTrafficPermitted="false" on the base config, so the app itself will not silently make HTTP calls to a captive-portal lookalike that intercepts HTTP requests.

We rely on Android’s built-in network-change handling for tunnel reconnects when you move between Wi-Fi and cellular. There is also an OS-level “Always-on VPN” toggle in the Android settings that you can pair with our app for stricter behavior. The steps are documented in our How to use page.

Practical checklist before you join a hotspot

A short, actionable list:

1. Turn off auto-join for networks you do not own. This shrinks the surface where your phone associates without your knowledge.
2. Use per-network MAC randomization (Android: long-press the network → Privacy → Randomized MAC).
3. Connect the VPN before you start a long-running task. The seconds between association and tunnel-up are when most cleartext probing happens.
4. Consider Always-on VPN with “Block connections without VPN.” This is an OS-level setting, not an app-level setting, and it limits leaks during the gap above.
5. Treat captive portals like the open web. The portal is HTTP for a reason (it has to work before TLS does), so do not hand it credentials you reuse elsewhere.

FAQ

Does a VPN make me safe on hotel Wi-Fi?

It contains a specific category of leakage (DNS, SNI, destination IP, the contents of any non-HTTPS traffic) between your device and our gateway. It does not protect you from things on your own device, like an installed root CA. The accurate framing is that a VPN narrows the trust set, not that it eliminates trust.

Why doesn’t HTTPS already do this?

HTTPS encrypts the body of a connection. It does not yet encrypt every piece of metadata: SNI is largely still in the clear, and DNS often is too unless your network or browser has rolled out encrypted resolvers. A VPN moves all of that into a single encrypted tunnel.

What use cases does TuxlerVPN Mobile officially support?

The full list, including “public Wi-Fi protection” and the activities the network is not for, lives in Supported & Prohibited Use Cases.