The HTTPS Padlock Is a Lie: Why Your ISP Still Sees Every Website You Visit + Video

By /

Listen to this Post

Featured Image

Introduction:

That reassuring padlock icon in your browser address bar has led millions to believe their browsing is private. While HTTPS encrypts the content of your communications—the passwords, messages, and financial data you transmit—it does not encrypt the destination of your traffic. Your Internet Service Provider (ISP) can still see every website you visit through a plaintext loophole called Server Name Indication (SNI), a critical component of the TLS handshake that has remained exposed since 2003. This article exposes the technical reality behind the padlock, demonstrates exactly how your ISP tracks you even with encrypted DNS enabled, and provides actionable commands to verify—and close—this privacy gap.

Learning Objectives:

  • Understand how Server Name Indication (SNI) leaks domain names in plaintext during the TLS handshake
  • Learn to capture and analyze SNI exposure using Wireshark and command-line tools
  • Compare privacy solutions: DoH/DoT, ESNI, ECH, and VPNs
  • Implement Encrypted Client Hello (ECH) on NGINX servers
  • Master practical commands to test, verify, and mitigate SNI leakage across Linux and Windows
  1. The SNI Leak: How Your ISP Reads Your Browsing History in Plaintext

When your browser initiates an HTTPS connection, it performs a TLS handshake with the server. The very first packet—the Client Hello—contains the Server Name Indication (SNI) field, which tells the server which domain name to present a certificate for. This is essential because multiple websites often share a single IP address (virtual hosting). The SNI field is transmitted in plaintext, unencrypted, for anyone on the network path to read.

Even if you enable “Private DNS” (DNS over HTTPS or DNS over TLS), which encrypts your DNS queries, your ISP can still see:
– The plaintext SNI in the TLS Client Hello
– The IP address of the destination server, often enough to identify the service
– Connection patterns and metadata that reveal behavior

Step‑by‑step guide to verify SNI exposure:

Linux / macOS (using tcpdump and openssl):

 Capture TLS Client Hello packets on port 443
sudo tcpdump -i any -1 -v 'tcp port 443' -c 10

For deeper analysis, capture to a file and inspect with Wireshark
sudo tcpdump -i any -w sni_capture.pcap 'tcp port 443'

Windows (using PowerShell and netsh):

 Start packet capture (requires admin)
netsh trace start capture=yes tracefile=c:\temp\sni_capture.etl maxsize=100

Stop capture after browsing to a few sites
netsh trace stop

Using curl to observe SNI behavior:

 Curl automatically sends the domain in SNI
curl -v https://www.example.com 2>&1 | grep -i "server name"

Spoof SNI (demonstrates how SNI can be manipulated)
curl --resolve www.example.com:443:192.0.2.1 https://www.example.com -k -v

The `–resolve` flag tells curl to connect to a specific IP but still send the domain name in the SNI field.

Analyzing the capture with Wireshark:

  1. Open the capture file (.pcap or .etl) in Wireshark
  2. Apply the filter: `tls.handshake.type == 1` (filters to Client Hello packets)
  3. Expand the TLS handshake → Extensions → server_name

4. Observe the domain name in plaintext

To add an SNI column for quick inspection:

  • Right-click on the server_name field
  • Select “Apply as Column”
  • All Client Hello packets now display the visited domain
  1. Encrypted DNS (DoH/DoT) Is Not a Silver Bullet

DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt your DNS queries, preventing your ISP from logging which domain names you resolve. However, this only plugs one hole while leaving others wide open.

What DoH actually hides:

  • The domain names you look up via DNS
  • The fact that you performed a DNS query at all (to some extent)

What DoH does NOT hide:

  • The SNI field in the TLS handshake (still plaintext)
  • The destination IP address
  • The volume and timing of your traffic

Step‑by‑step guide to configure DoH and test its limitations:

Enable DoH in Firefox:

1. Navigate to Settings → Privacy & Security

2. Scroll to DNS over HTTPS

  1. Select “Increased Protection” and choose Cloudflare or NextDNS

Enable DoH system-wide on Linux (using systemd-resolved):

 Edit /etc/systemd/resolved.conf
sudo nano /etc/systemd/resolved.conf

Add these lines:
[bash]
DNS=1.1.1.1
DNSOverTLS=yes
DNSSEC=yes

Restart the service
sudo systemctl restart systemd-resolved

Enable DoH on Windows:

1. Settings → Network & Internet → Wi-Fi/Ethernet

  1. Hardware properties → DNS server assignment → Edit

3. Set DNS to `1.1.1.1` and `1.0.0.1`

4. Enable “Encrypted DNS (DNS over HTTPS)” preference

Test the limitation—capture traffic after enabling DoH:

 With DoH enabled, browse to a site and capture
sudo tcpdump -i any -w doh_test.pcap 'tcp port 443'

Open in Wireshark—the SNI will still be visible in plaintext
 despite DNS queries being encrypted

The SNI leak remains because the browser must tell the server which certificate to present before the encrypted tunnel is established.

3. Encrypted Client Hello (ECH): The Real Fix

Encrypted Client Hello (ECH) is the next-generation standard that finally closes the SNI leak. ECH encrypts the entire Client Hello message—including the SNI, ALPN negotiations, and other extensions—using a public key retrieved from the server’s DNS.

To outside observers, the connection appears to go to a “cover” domain (the ECH public_name), while the actual destination remains hidden until after the secure tunnel is established.

Current ECH adoption status:

  • Less than 19% of the top 1 million domains support ECH
  • Cloudflare enables ECH by default for zones using their authoritative DNS
  • NGINX 1.29.4+ natively supports ECH
  • Firefox and Chrome have experimental ECH support

Step‑by‑step guide to enable ECH on NGINX:

Prerequisites:

  • NGINX 1.29.4 or higher compiled with OpenSSL 3.0+ or BoringSSL
  • DNS provider supporting HTTPS or SVCB records

Configure NGINX for ECH:

 /etc/nginx/nginx.conf
server {
listen 443 ssl;
server_name example.com;

ssl_certificate /etc/nginx/ssl/example.com.crt;
ssl_certificate_key /etc/nginx/ssl/example.com.key;
ssl_protocols TLSv1.3;

Enable ECH
ssl_ech on;
ssl_ech_keys /etc/nginx/ssl/ech_keys.pem;
}

Generate ECH keys:

 Generate ECH key pair (requires OpenSSL 3.0+)
openssl ech -keyout /etc/nginx/ssl/ech_keys.pem -pubout \
/etc/nginx/ssl/ech_pubkey.pem

Publish ECH configuration via DNS (HTTPS record):

 DNS HTTPS record format:
example.com. 3600 IN HTTPS 1 . alpn="h2" ech="AEX+..."

The `ech` parameter contains the base64-encoded public key and configuration.

Test ECH with curl (version 8.0+ with ECH support):

 Test ECH-enabled domain
curl --ech https://example.com -v

4. VPNs: The Only Definitive Solution Today

Until ECH achieves widespread adoption, a VPN (Virtual Private Network) remains the only reliable method to hide your browsing activity from your ISP.

A properly configured VPN:

  • Encrypts all traffic between your device and the VPN server
  • Hides both DNS queries and SNI from your ISP
  • Masks your source IP address

Step‑by‑step guide to verify VPN effectiveness:

Before VPN connection:

 Check your public IP and DNS
curl ifconfig.me
dig example.com

Capture traffic while browsing
sudo tcpdump -i any -w before_vpn.pcap 'tcp port 443'

After VPN connection:

 Connect to VPN (example using OpenVPN)
sudo openvpn --config /path/to/vpn.ovpn

Verify IP has changed
curl ifconfig.me

Capture again
sudo tcpdump -i any -w after_vpn.pcap 'tcp port 443'

Compare captures in Wireshark:

  • Before VPN: SNI shows the actual domain, source IP is your public IP
  • After VPN: SNI shows the VPN server domain, source IP is the VPN provider’s IP

Windows VPN configuration (built-in):

1. Settings → Network & Internet → VPN

2. Add a VPN connection

3. Enter server address, credentials, and connection type

  1. Connect and verify with `curl ifconfig.me` in PowerShell

5. Bypassing Censorship with SNI Manipulation

In some regions, ISPs and governments use Deep Packet Inspection (DPI) to block access based on SNI values. Several tools can bypass these restrictions by manipulating or fragmenting the SNI field.

SpoofDPI is a lightweight, cross-platform proxy that bypasses DPI by sending fragmented Client Hello packets.

Install and configure SpoofDPI on Linux:

 Download and build
git clone https://github.com/xkairbekov/bypassDPI.git
cd bypassDPI
go build

Run with DoH for encrypted DNS
./bypassDPI --doh-url https://cloudflare-dns.com/dns-query

Fake SNI techniques send a legitimate-looking SNI (e.g., www.google.com) while tunneling the actual request. This tricks DPI systems while the real destination is negotiated after the TLS handshake.

Using curl with spoofed SNI:

 Connect to IP but send a different domain in SNI
curl --resolve spoofed.com:443:203.0.113.1 https://spoofed.com \
--header "Host: actual-site.com" -k

Caution: These techniques are for educational and legitimate circumvention of censorship only. Misuse may violate terms of service.

6. Enterprise Mitigation: Monitoring and Blocking SNI Leakage

Organizations must monitor SNI leakage to meet compliance requirements like HIPAA, GLBA, and NIST 800-53. Security teams can use SNI data for threat hunting while implementing controls to prevent exposure.

Step‑by‑step guide to detect SNI exfiltration with Wireshark:

Custom Wireshark filter for SNI monitoring:

tls.handshake.type == 1 && tls.handshake.extensions_server_name

Export SNI data to CSV for analysis:

 Using tshark (Wireshark CLI)
tshark -r capture.pcap -Y "tls.handshake.type == 1" \
-T fields -e ip.src -e ip.dst \
-e tls.handshake.extensions_server_name \
-E header=y -E separator=, > sni_export.csv

Enterprise NGINX configuration to log SNI:

log_format sni_log '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'SNI:$ssl_server_name';

access_log /var/log/nginx/sni_access.log sni_log;

What Undercode Say:

  • The padlock is not a privacy shield—HTTPS encrypts content but not destinations. The SNI field has been leaking domain names in plaintext since 2003, and most users remain unaware.
  • Encrypted DNS (DoH/DoT) is necessary but insufficient—it fixes DNS leakage but does nothing to protect SNI, which is arguably the more critical exposure.
  • ECH is the long-term solution, but adoption is slow—less than 19% of top domains support it, and browser implementation remains experimental. Until then, VPNs remain the gold standard.
  • Privacy is a layered defense—no single technology solves all problems. A combination of DoH, ECH (where available), VPNs, and cautious browsing habits is required.
  • ISP tracking is real and pervasive—ISPs log SNI data, sell browsing history, and comply with government surveillance requests. The technical capability to monitor every website you visit exists today.
  • Corporate networks also see your SNI—employers, schools, and public Wi-Fi administrators can see every domain you visit, even with HTTPS.
  • The future is encrypted by default—as ECH deployment grows, the web moves closer to true end-to-end privacy. Organizations like Cloudflare, NGINX, and major browsers are driving this transition.

Prediction:

  • +1 ECH will become the default standard for TLS 1.3 connections within 3–5 years, making SNI leakage a relic of the past. Major CDNs and browsers will drive adoption, and regulatory pressure will accelerate deployment.

  • +1 VPN usage will continue to surge as privacy awareness grows, with consumer VPNs evolving to integrate ECH natively, creating multi-layered protection against ISP surveillance.

  • -1 Until ECH achieves critical mass, ISPs will continue to monetize browsing history, and surveillance capabilities will expand with more sophisticated DPI systems that analyze traffic patterns even when SNI is encrypted.

  • -1 The transition to ECH will create temporary compatibility issues—corporate proxies, legacy firewalls, and content filtering systems that rely on SNI inspection will break, forcing organizations to upgrade or adopt alternative monitoring strategies.

  • +1 Open-source web servers (NGINX, Apache) and privacy-focused browsers (Firefox, Brave) will lead ECH adoption, making privacy accessible to both enterprises and individual users without requiring proprietary solutions.

  • -1 State-level adversaries will develop countermeasures to ECH, such as blocking ECH-enabled connections entirely or forcing the use of non-ECH-compliant browsers in regulated environments, creating a new battleground in the censorship-vs-privacy arms race.

▶️ Related Video (78% Match):

https://www.youtube.com/watch?v=3GV89k7c99g

🎯Let’s Practice For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

IT/Security Reporter URL:

Reported By: Chuckkeith Https – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: