HTTPS Lock Icon Present but List of Visited Sites Remains Visible

Even when HTTPS is active and passwords stay protected, DNS queries and the SNI field in TLS handshakes expose the exact domains a user visits over public Wi-Fi. Classic unencrypted DNS over UDP sends domain names in plaintext, allowing anyone on the same network to observe them with simple packet captures. The SNI extension reveals the target hostname before encryption is negotiated, enabling domain-based filtering without decrypting traffic. DNS over HTTPS moves queries inside encrypted channels but shifts visibility to the chosen resolver instead of the local network. Encrypted Client Hello offers partial protection for SNI yet requires support from both browsers and server infrastructure. The practical takeaway is that metadata about services used, timing, and frequency leaks more readily than credentials in modern public networks.

HabrTranslated from Russian

Read at source

Public Wi-Fi prompts two common reactions: either passwords are stolen so avoid it, or HTTPS makes everything safe. Both views are imprecise and obscure what actually occurs on the wire.

Passwords remain safe under working HTTPS. However, the list of visited sites stays visible to the access point owner, the ISP, or any neighbor on an open network. No cracking is required; the information travels in plaintext.

First: DNS

Before loading a site, the device queries a DNS server for the IP address. Classic DNS uses UDP without encryption, so the domain name travels openly. A capture with tshark -i any -f "udp port 53" immediately shows requested names such as habr.com or example.org. The access point owner sees every domain from every connected device. Background queries from updates and messengers continue even after sites are closed, allowing usage patterns to be reconstructed.

Second: SNI

Encrypting DNS does not solve the next step. During TLS setup the client sends the Server Name Indication (SNI) in the first handshake message, before encryption is established. A capture filtered on tcp port 443 and the tls.handshake.extensions_server_name field reveals both the destination IP and the hostname. This plaintext field powers domain-based blocking and filtering without any decryption.

What stays hidden includes full request paths, parameters, page content, files, messages, passwords, and cookies. Certificate mismatches also trigger browser warnings, preventing content tampering.

The outdated warning about stolen bank passwords on café Wi-Fi is roughly ten years old. The real exposure is metadata: which services are used, when, and how often. Packet sizes and timing can further distinguish specific videos from a known set, though this requires more effort.

How to close DNS leaks

Modern browsers support DNS over HTTPS. In Firefox the setting is under Privacy & Security; in Chrome it appears under Security. After activation, UDP port 53 queries from the browser disappear. System-wide resolvers must be configured separately. The change simply moves visibility from the local network to the selected resolver operator.

How to close SNI leaks

Encrypted Client Hello encrypts the SNI field but needs support from both the browser and the destination site plus its CDN. Firefox offers the toggle in network settings; Chrome lists it among experimental flags. Coverage remains incomplete, so unprotected sites still leak the name in plaintext.

The only reliable method today is a VPN tunnel, which again relocates observation to the tunnel provider. DNS leaks outside the tunnel, traffic before the tunnel connects, and the mere fact of tunnel use remain visible to the local network.

Meridian digestThe week's most consequential security stories, distilled into one briefing.See the digest

More in Privacy & Surveillance

Maximizing iPhone Privacy: Essential Settings to Enable, Disable, and Verify Immediately
Top 10 Secure DNS Servers for Privacy, Threat Blocking and Ad Filtering in 2026
WebRTC IP Leaks Explained: Why Disabling the Protocol Harms Anonymity in Anti-Detect Browsers