The captive portal on an airport network asks for your mobile number, sends an OTP, and then loads a page your browser flags with a certificate warning. That is the moment worth paying attention to, and it is also the moment nearly everybody clicks through, because the alternative is no internet while a delayed flight slides further down the board. Look around any departure lounge in India and you will count a dozen laptops on that same network, belonging to people who have been told for years that public Wi-Fi is dangerous and are using it anyway. Both halves of that are interesting. The blanket warning is largely out of date, because the web changed underneath it and encryption became the default rather than the exception. The specific risks that remain are narrower, more practical, and worth knowing precisely, because the advice that follows from them is different advice.
what HTTPS already handles
The scary advice about café networks comes from an era when most of the web was unencrypted. Someone on the same network really could watch your session and read what you typed. That era ended. Essentially every site that matters now uses HTTPS, browsers warn loudly about plaintext pages, and HTTPS-only mode refuses them outright.
So on a modern device, another customer in that café cannot read your email contents, your messages or your banking session. The encryption is negotiated end to end between your device and the server, and the network in between carries sealed traffic it cannot open. That is a genuine, structural improvement, and it is why blanket panic about hotel Wi-Fi is now out of proportion to the threat.
What the network operator can still see is which sites you reach, through your DNS lookups, the addresses you connect to, and the hostname announced in the TLS handshake. Domains, not contents. Encrypted DNS closes part of that gap and not all of it, which I worked through in the encrypted DNS guide.
| On a café network | Visible to others |
|---|---|
| What you type into a HTTPS site | No |
| Which sites you visit | Yes, to the network operator |
| Your device name and rough traffic pattern | Yes |
| Files you have shared on your machine | Only if sharing is switched on |
| Your session if you ignore a certificate warning | Yes, that warning is the whole defence |
the risks that genuinely remain
captive portals
The login page is the weakest part of any public network. It has to intercept your first request to appear at all, which means it behaves exactly like the thing you are told to watch out for. Portals that ask for a phone number and OTP are common in India, and there is no way for you to verify who receives that number. My rule is narrow: give the portal the minimum it demands, never a password you use elsewhere, and treat any certificate warning on a portal page as a full stop rather than a speed bump.
a network with a familiar name
Anyone can run an access point and call it whatever they like, including the name of the café you are sitting in. Your phone will happily reconnect to a name it remembers, in a different city, offered by different hardware. That is the risk worth acting on, and the fix is two settings: turn off automatic connection to open networks, and remove saved public networks you are done with.
the wrong domain
Most accounts that go wrong on a public network do so because someone signed in on a lookalike page, not because the Wi-Fi was compromised. A mistyped bank domain or a link from a message does the same damage on your home connection. A password manager that declines to autofill on a domain it does not recognise is the best defence available here, which is one of several reasons it sits at the top of my list in password managers and 2FA.
your own unpatched device
A shared network puts your machine within reach of every other machine on it. A laptop with current updates and a firewall on ignores that attention. A Windows install three months behind on patches, with file sharing enabled from the time you were copying photos to a cousin’s laptop, is a different proposition. This is the risk people underestimate while worrying about encryption that is already fine.
so is a VPN warranted
Sometimes, for a narrower reason than the ads suggest. A VPN on a café network does two useful things: it keeps the domains you visit away from the network operator, and it gives you one consistent path out regardless of what the local network does with DNS. It does not protect you from a lookalike login page, an unpatched laptop, or anything you choose to type in. The trust shifts to whoever runs the VPN, and the VPN explainer walks through what that operator can see.
Who I think should bother: journalists, anyone handling client data on the road, people working from co-working spaces and hotel networks regularly, and anyone whose employer requires it. Who I think should not lose sleep: a student on college Wi-Fi checking email and watching lectures, with an updated device and a password manager.
If you do want a tunnel, running your own gives you an exit you actually control. Using your home connection as the exit while travelling is a couple of taps once the mesh is in place, and that setup is described in the Tailscale guide. The trade-off is that your home upload speed becomes the ceiling for everything you do.
the simpler Indian answer: use your own data
Mobile data here is cheap and plentiful in a way it is not in most countries. Most prepaid packs include a daily allowance that comfortably covers a few hours of laptop work, and 4G or 5G coverage in cities beats the average café router for both speed and consistency. Given that, the security question often has a boring answer: skip the public network entirely and tether.
A hotspot means no captive portal, no shared segment, no saved network to worry about later. Two caveats. Watch the daily cap if you are pushing a large upload, because a tethered laptop can consume a day’s allowance faster than you expect, and update downloads have a habit of waking up on a metered connection. And your phone will get warm and drain, so keep it charging. The habit worth stealing: café Wi-Fi for a big download when you want to spare your quota, your own data for anything involving a login.
settings to change before you connect
On Windows, the one that matters is the network profile. Public tells Windows to hide your machine from discovery on that network; Private does the opposite, and people click it out of habit when the prompt appears. Run these in PowerShell opened as Administrator.
# Check what your laptop actually applied to the network it is on
Get-NetConnectionProfile
# Force it to the safer profile
Set-NetConnectionProfile -Name "AirportFreeWiFi" -NetworkCategory Public
# Sanity check that sharing rules are not enabled for public networks
Get-NetFirewallRule -DisplayGroup "File and Printer Sharing" | Format-Table Name, Enabled, ProfileOn Android, open the saved networks list and turn off automatic reconnection for anything public, then forget the ones you will not use again. Switch off Quick Share (formerly Nearby Share) visibility and Bluetooth discoverability while you are in there. On both platforms, let the operating system finish its pending updates before you take the machine travelling, not while sitting on the airport network.
a working checklist
- Ask the staff for the actual network name rather than picking the most plausible one on the list.
- Set the network profile to Public when your laptop asks, every time.
- Give the captive portal the minimum, and abandon it if the certificate looks wrong.
- Check for the padlock before typing anything into a form, and stop at any warning.
- Let the password manager fill credentials, so the domain is verified for you.
- Switch to your hotspot for banking, or simply postpone it by an hour.
- Forget the network when you leave, so your phone does not go looking for it in another city.
common mistakes
- Clicking through a certificate warning to finish a portal login. That warning is the one protection that cannot be replaced by anything else on this list.
- Choosing Private when Windows asks about a hotel network, which switches on discovery exactly where you do not want it.
- Leaving automatic connection to open networks enabled, so the phone joins anything with a remembered name.
- Reusing a real password on a captive portal that asks you to create an account.
- Assuming a VPN covers judgement. It moves your traffic, not your attention to the domain in the address bar.
- Travelling with a device that has pending updates, then applying them over a network you do not trust.
FAQ
can I do UPI payments or banking on café Wi-Fi?
Technically yes, since the app’s connection is encrypted and many banking apps refuse to connect if the certificate looks wrong. In practice, switching to mobile data is simpler, because a failed payment on a flaky network is annoying and because a bank app that refuses to load leaves you guessing about why. It costs nothing to wait for a better connection.
is a password-protected café network safer than an open one?
Slightly, and less than you would hope. A shared passphrase everyone knows is not much of a secret, though WPA3 improves the situation meaningfully over older networks. Treat a network with a password on a printed card as public, because functionally it is.
what about public charging points?
Use a wall adapter where you can, or a cable that carries power only. Modern phones ask before granting data access over USB, so the risk is lower than the headlines suggest, but a power bank removes the question entirely. Check CERT-In’s current advisories for any guidance on public charging points.
The version to remember: HTTPS handles the eavesdropping problem, so your attention belongs on the portal page, the domain you are signing into, and whether your device is patched. Automatic connection to open networks is the one setting worth switching off before your next trip, and for moving money, your own data is the simpler answer.
Update history: Android’s sharing feature is now called Quick Share, the banking-app and CERT-In charging statements are more precise, and the PowerShell commands note that they need an Administrator window.
Sources
- CERT-In — India’s national computer emergency response team, source for current advisories on public networks and charging points.
- RFC 8446 — TLS 1.3, which defines what is encrypted end to end and what stays visible to the network.
- MDN web security documentation — certificate warnings, HTTPS enforcement and mixed content behaviour in browsers.