HabrAugust 27, 2026🇷🇺Translated from Russian

HTTPS Lock Icon Present but List of Visited Sites Remains Visible

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.

Related articles

HabrPrivacy & Surveillance

Russian TSPU Begins Intercepting UDP DNS Queries to Cloudflare and Google Public Resolvers

Starting on the evening of August 26, Russia's TSPU DPI system began actively intercepting plaintext DNS queries sent over UDP to public resolvers operated by Cloudflare and Google. Queries to 1.1.1.1 and 8.8.8.8 now return NXDOMAIN responses for blocked domains instead of the real IP addresses. The interception works exclusively on UDP; TCP-based DNS queries continue to receive legitimate answers from the original resolvers. Technical analysis shows the system performs targeted DNAT, rewriting the destination IP to the NSDI server at 195.208.5.1 only when a DNS query is detected inside the packet. Experiments with varying TTL values confirm that the redirection occurs after the traffic passes the TSPU node, and rapid successive queries can sometimes bypass the filter and return genuine records. The change affects netflow statistics visible to network operators, as traffic previously destined for foreign resolvers is now redirected domestically.

AntiMalwarePrivacy & Surveillance

Google Develops Public Android API for On-Device Content Safety Classification

Google is creating a new public Android API that will allow third-party applications to analyze images and other files locally on the device and assign them one of four safety statuses. The system builds on the existing SafetyCore component already used in Google Messages to blur intimate images. ContentSafetyManager will process images, raw files, and multimedia content entirely on-device without transmitting data to Google servers. Applications will then decide whether to display, blur, or hide the content based on the classification result. Experts warn that malicious apps granted broad permissions could misuse the classifier to scan large volumes of user files and build detailed profiles. SafetyCore itself previously sparked controversy after being installed automatically without explicit user consent and without a visible icon, leading some users to install blockers to prevent reinstallation via the Play Store. Google continues to emphasize minimal permission requests and local processing as safeguards for user privacy.

BoletimSecPrivacy & Surveillance

WhatsApp Adds Support for Multiple Passkeys on Single Account

WhatsApp has expanded its account protection features by allowing users to register more than one passkey on the same profile. The update particularly benefits users who switch between Android and iOS devices while maintaining phishing-resistant login methods. Passkeys replace traditional codes and passwords with biometric authentication, facial recognition, or device lock mechanisms. Meta reports that more than one billion people already use the feature on WhatsApp, with Android support introduced in 2023 and iOS support added in 2024. The change reduces reliance on a single device during authentication by associating multiple keys with one account. Users can manage keys through Settings > Account > Passkeys. WhatsApp has also strengthened two-factor verification by allowing replacement of the six-digit PIN with longer passwords containing letters, numbers, and special characters.

AntiMalwarePrivacy & Surveillance

Russian ISPs Begin Disrupting Encrypted DNS Services from Google and Cloudflare

Users of several major Russian internet providers have reported widespread issues accessing encrypted DNS protocols offered by Google and Cloudflare. The affected services include DNS over HTTPS (DoH) and DNS over TLS (DoT), which are designed to prevent providers from inspecting domain queries. Measurements show that connections to Cloudflare addresses 1.1.1.1 and 1.0.0.1 on port 853 establish TCP handshakes but are then reset with ECONNRESET errors before TLS authentication completes. Google Public DNS endpoints experience different interference, with sessions stalling after the TLS ClientHello or terminating with unexpected EOF errors. The disruptions have been observed across Rostelecom, Dom.ru, Tattelecom, and SkyNet subscribers, with varying impact depending on region and operator. Tattelecom support reportedly advised one customer to disable both protocols to restore connectivity. No official confirmation of centralized blocking has been issued, yet the coordinated pattern across multiple providers suggests deliberate interference rather than random failure.