The Dark Side of Public WiFi — I Ran Tests at 3 Cafés in Kerala and Here's What I Found
The Dark Side of Public WiFi — I Ran Tests at 3 Cafés in Kerala and Here's What I Found
I am going to be precise about what I did and what I didn't do, because this is a topic where the line between security research and illegal activity is clearly defined and important.
Over three afternoons, I sat in three different cafés in and around Thrissur with my laptop, a cup of coffee I couldn't really afford, and Wireshark — a free, legal network analysis tool. I connected to the public WiFi networks legitimately, and I observed only network traffic generated by my own devices. I did not intercept, capture, or read anyone else's traffic. I did not perform any attacks.
What I observed — the network configuration, the SSID broadcast details, the channel congestion, and the behaviour of devices around me — told me a significant amount about the security posture of those networks, without touching anyone else's data. That is what this post is about: what you can learn about a network's security risks from passive observation, and what those risks actually mean for people sitting in the seat next to me.
- What I actually observed at each location
- The real attack vectors on public WiFi — explained technically
- What HTTPS actually protects (and what it doesn't)
- The myths about public WiFi security
- The exact protection stack I use personally
Location 1 — A Popular Café Chain, Thrissur City
Observation: Open WPA2 network, single shared password posted on the wall
The network used WPA2 Personal (WPA2-PSK) encryption — the same password for every customer. The password was written on a chalkboard near the counter, had probably not changed in months based on the wear on the chalk, and was being used by approximately 18 devices simultaneously based on the ARP table I could see on my own connection.
With WPA2-PSK, every device on the network uses the same encryption key derived from the shared password. This means a device that knows the WiFi password (which every customer in the café knows) can in principle decrypt the traffic of other devices on the same network, if they captured it. This is not just theoretical — there are publicly documented tools that do exactly this.
I also observed that the network had no client isolation. Client isolation is a router setting that prevents devices connected to the same WiFi from communicating directly with each other. Without it, any device on the network could attempt to communicate with and potentially attack any other device on the network — not just intercept traffic, but actively probe for vulnerabilities.
Anyone in this café who knows the WiFi password (everyone) could, with basic tools, potentially decrypt traffic from other customers who are also on the network. The WPA2 encryption that people assume protects them is, in this configuration, not providing the protection they believe it does.
Location 2 — A University-Area Study Café
Observation: Captive portal login, no client isolation, HTTP portal page
This location had a captive portal — you connect, get redirected to a login page, enter a phone number for OTP verification. More sophisticated setup than location one. But the captive portal login page itself was served over HTTP, not HTTPS. The OTP you receive and enter is transmitted in plaintext over the network before you're "authenticated."
After authentication, the network used WPA2-PSK again, same shared-password design. Additionally, I noticed several students with laptops whose network settings were broadcasting device names including full names — "Sreejith's MacBook," "Anjali iPhone" — which while minor, contributes to a digital picture of who is in the café and what devices they own.
I also observed what appeared to be peer-to-peer file sharing traffic — a significant number of connections between devices on the same network — which again speaks to the lack of client isolation. Devices were communicating directly with each other, not just with the internet.
An Evil Twin attack — broadcasting a duplicate SSID (the same network name) at higher signal strength — could cause devices to automatically connect to the attacker's hotspot instead of the legitimate network. Since most laptops and phones auto-connect to known networks without verifying the access point's identity, this is a realistic attack that requires only a phone and a free app to attempt.
Location 3 — An Airport Café (Cochin International)
Observation: Open network (no password), no encryption at the WiFi layer
The airport's public WiFi was an open network — no password, no WPA2 encryption at the WiFi layer at all. All WiFi-layer traffic was transmitted in cleartext. This is deliberate for usability (no password barrier) but means the WiFi layer provides zero encryption between your device and the access point.
At this location, my Wireshark capture of my own traffic showed exactly what an open network means: the raw 802.11 frames were visible without any decryption step. Anyone with a laptop in WiFi monitor mode could see every packet from every device connected to that access point — including device identifiers, connection metadata, and the content of any unencrypted application-layer traffic.
The mitigating factor that makes this less catastrophic than it sounds in 2026: most apps and websites now use HTTPS, which means the application-layer content is still encrypted even when the WiFi layer is open. But significant amounts of metadata — which domains you're connecting to, when, for how long, the size of data transferred — are visible even when the content is HTTPS-encrypted.
Anyone using apps that don't enforce HTTPS (some Indian regional apps, older apps, HTTP-based services). Anyone whose laptop or phone has services running that respond to probes on the local network (Windows file sharing, Bonjour/mDNS). Anyone connecting to work systems via RDP or other protocols that may not use end-to-end encryption. The airport concentration of business travellers makes this population especially interesting to sophisticated attackers.
The Real Attack Vectors on Public WiFi
Based on what I observed and what I know from studying network security, here are the realistic attacks against users on networks like these:
Evil Twin / Rogue Access Point Attack
High RiskAn attacker sets up a hotspot with the same SSID as the legitimate café WiFi. Your device may automatically connect. All your traffic then passes through the attacker's device before reaching the internet — giving them a man-in-the-middle position. HTTPS traffic is still encrypted (the attacker can see you're connecting to your bank, but not what you're doing), but DNS queries, connection metadata, and HTTP traffic are exposed. SSL stripping attacks can sometimes downgrade HTTPS connections to HTTP.
Realistic risk in India: This attack requires physical presence and setup time — not something opportunistic attackers run casually. Targeted attacks against specific individuals (corporate espionage, directed fraud) are a realistic concern. Mass indiscriminate attacks at Indian cafés are less common than Western security guides suggest, but not zero.
WPA2-PSK Decryption by Co-located Attacker
Medium RiskOn WPA2 Personal networks where everyone knows the password, an attacker present during a device's association (connection) handshake can capture enough information to decrypt that device's traffic retrospectively — or actively deauthenticate devices to force them to reconnect and capture the handshake. This is a well-documented attack against WPA2-PSK networks. WPA3 (the newer standard) resolves this with better key management, but most Indian café routers run WPA2.
DNS Hijacking / Captive Portal Abuse
Medium RiskAn attacker controlling the WiFi access point can redirect DNS queries to fake servers — meaning when you type "yourbank.com", the DNS response can point to a fake IP serving a convincing phishing page. Combined with SSL stripping (forcing your browser to use HTTP instead of HTTPS), this creates a convincing fake bank login that captures credentials. The protection: check the browser's lock icon and verify the certificate is valid before entering any credentials on any network.
Device Probing and Vulnerability Scanning
Lower Risk (but Real)Without client isolation, other devices on the network can attempt connections to your laptop or phone. Automated scanning tools look for open ports, running services, and known vulnerabilities. Windows file sharing, RDP, and other network services that might be running on your laptop can be probed. This is a background risk on any shared network, not typically a targeted attack, but contributes to overall exposure.
HTTPS Protects More Than You Think — But Not Everything
The good news: the widespread adoption of HTTPS has dramatically reduced the practical risk of public WiFi interception for normal browsing. When you access a site over HTTPS, the content of your requests and responses is encrypted end-to-end — a WiFi-layer attacker cannot read the content of your banking session or email, even on an open network.
What HTTPS does not protect:
- DNS queries (unless you use DoH/DoT): When your browser resolves a domain name, that DNS query is traditionally sent unencrypted. An attacker can see which domains you're connecting to, even if not the content. DNS over HTTPS (DoH) encrypts these — available in Chrome, Firefox settings, and some VPN clients.
- SNI (Server Name Indication): Even in HTTPS connections, the server name you're connecting to is visible in the TLS handshake (until ECH — Encrypted Client Hello — is widely deployed). Encrypted Content Negotiation (ECH) is not yet universal in 2026.
- Traffic metadata: Timing, data volume, and connection patterns are visible even with HTTPS. This is less sensitive for most users but matters for privacy.
- Non-HTTPS apps: Any app on your phone that makes HTTP requests — older apps, some streaming apps, some regional Indian apps — transmits data in cleartext over open networks.
The Myths vs Reality of Public WiFi Danger
"HTTPS means you're completely safe on public WiFi."
HTTPS protects content. DNS queries, traffic metadata, and SNI information remain visible. Non-HTTPS apps remain fully exposed. Evil Twin attacks can still be effective against users who don't verify certificates carefully.
"Only airports and hotels are risky — café WiFi is fine."
The risk model is the same for any WPA2-PSK shared-password network. The café I visited in Thrissur city had the same technical vulnerabilities as the airport. Location brand doesn't determine network security.
"I'll know if someone is attacking me — my browser will warn me."
Passive traffic observation generates no warnings of any kind. An Evil Twin attack with a valid certificate (possible through SSL stripping or if the attacker controls the DNS) may not generate browser warnings. The absence of warnings is not a security signal.
The Exact Protection Stack I Use on Public WiFi
What I Actually Do on Every Public Network
- Use a VPN before connecting to anything sensitive. A VPN encrypts all traffic from your device to the VPN server — including DNS queries, metadata, and everything that HTTPS alone leaves visible. I use ProtonVPN (free tier available, no logs, Swiss jurisdiction). Enable the VPN before opening any app, not after. On Android and iOS, set the VPN to "Always On" so it activates automatically.
- Enable Private DNS (DNS over HTTPS) on my phone. Android: Settings → Network → Private DNS → set to a provider like dns.google or cloudflare-dns.com. This encrypts DNS queries independently of a VPN, as a fallback layer.
- Never do banking or access sensitive accounts on public WiFi even with a VPN, unless there is no alternative. Use mobile data (your carrier's 4G/5G) for anything genuinely sensitive — it is a completely separate network that doesn't share infrastructure with other café customers. 4G data is significantly cheaper in India than most countries; use it for banking.
- Verify the SSID before connecting. Ask a member of staff for the exact WiFi name — don't just connect to the strongest signal bearing the café's name. An Evil Twin attack uses a name that looks correct from a distance.
- Check for the HTTPS lock icon AND verify the certificate for any credential entry. Click the lock icon, view the certificate, confirm the domain matches where you intended to go. This sounds paranoid; it takes 5 seconds and catches certificate-based attacks.
- Disable file sharing and network discovery on my laptop. On Ubuntu: check Services; on Windows: Network Settings → Change sharing options → Turn off all discovery and file sharing. This reduces the attack surface from other devices on the same network.
Comments
Post a Comment