Imagine you’ve spent the afternoon fortifying your digital castle. You’ve moved your browsing over to HTTPS so that no one can sniff your traffic. You’ve read up on privacy, so you went into your browser settings and enabled DNS over HTTPS (DoH) to encrypt your domain name queries. You sit back, confident that your Internet Service Provider (ISP) is now completely blind to your online habits.
You feel safe. You feel anonymous.
You are also completely wrong.
Despite the massive strides the tech industry has made in encrypting the web, the fundamental architecture of the internet relies on protocols that were never designed for total privacy. Even if you lock down your DNS and encrypt your web traffic, your ISP still has a front-row seat to exactly which websites you visit.
Here is a deep dive into the technical loopholes from IP routing to the TLS handshake that keep your browsing history wide open to your provider.
1. The Fundamental Illusion: HTTPS and DoH
To understand why your privacy is still leaking, we first need to acknowledge what HTTPS and DoH actually protect. They are incredibly important tools, but they are frequently misunderstood.
What HTTPS Does (and Doesn’t Do)
HTTPS (Hypertext Transfer Protocol Secure) encrypts the data exchanged between your browser and a specific web server. When you connect to your bank via HTTPS, an attacker or your ISP cannot see your password, your account balance, or the specific subpages you are visiting (e.g., they don’t see bank.com/accounts/secret-id).
However, HTTPS only encrypts the content of the communication. It does not obfuscate the connection itself. The data packets still need to physical travel from your device, through your ISP’s routers, to the destination server.
What DoH Solves (and What It Leaves Behind)
Traditionally, when you type example.com into your browser, your computer sends a plain-text DNS request to find that website’s IP address. Your ISP handles this request and can log every single domain you look up.
DNS over HTTPS (DoH) fixes this specific flaw. It wraps your DNS queries inside an encrypted HTTPS stream and sends them to a third-party resolver (like Cloudflare or Quad9). To your ISP, this looks like generic, encrypted traffic moving to a single IP address. Your ISP can no longer see your raw DNS lookups.
So, if your DNS requests are hidden and your web traffic is encrypted, how does the ISP still catch you? The answers lie in the unencrypted scaffolding of network routing and cryptography.
2. Leak #1: Destination IP Addresses (The Routing Layer)
The most unavoidable reason your ISP knows where you are going is the Internet Protocol (IP) address.
The internet is fundamentally a packet-routing network. When you request data from a website, your computer breaks that request into packets. Every packet requires a Source IP (your home address) and a Destination IP (the website’s address) stamped clearly on its outer header.
+-------------------------------------------------------------+
| IP PACKET HEADER |
| Source: 192.168.1.50 --> Destination: 104.244.42.1 | <-- VISIBLE TO ISP
+-------------------------------------------------------------+
| [ Encrypted TLS / HTTPS Payload: Content hidden ] |
+-------------------------------------------------------------+
Because your ISP owns the physical routers and cables that move these packets, they must read the destination IP address to know where to send the data. They cannot route a packet blindly.
The Catch: Mapping IPs to Domains
“But wait,” you might argue, “an IP address is just a string of numbers. It doesn’t explicitly name the website!”
While true in theory, in practice, it is trivial for an ISP to match an IP address to a specific domain name.
- Reverse DNS Lookups: The ISP can automate reverse DNS lookups on the IPs passing through their gateways to instantly map them back to domains.
- Whose IP is it anyway? If the IP belongs to a dedicated server for a specific company (e.g., a specific bank or a niche forum), the ISP instantly knows exactly who you are communicating with.
The Nuance of Shared Infrastructure (CDNs)
If a website sits behind a massive Content Delivery Network (CDN) like Cloudflare, Akamai, or Fastly, or shares an IP address on a crowded virtual host, the destination IP might just point to a massive multi-tenant server. In this specific scenario, your ISP might only know you are talking to a Cloudflare-hosted site, but not which specific one based on the IP alone.
Unfortunately, the next set of protocols strips away even this layer of ambiguity.
3. Leak #2: Server Name Indication (SNI)
Even if a website hides behind a shared CDN IP address, your browser will usually give away the exact domain name during the very first fraction of a second of the connection. This happens via a mechanism called Server Name Indication (SNI).
When your browser initiates an HTTPS connection, it performs a TLS Handshake to establish encryption keys with the server. If a single IP address hosts hundreds of different websites, the server needs to know which SSL/TLS certificate to present to your browser.
To solve this, your browser sends the target domain name (e.g., targetwebsite.com) in clear text during the initial Client Hello phase of the handshake.
Because this happens before the encrypted tunnel is fully built, the SNI is completely unencrypted. Any intermediate node most notably your ISP can passively sniff this packet and log the precise website name you are trying to reach.
Why Encrypted Client Hello (ECH) Isn’t a Silver Bullet Yet
There is an extension to the TLS protocol called ECH (Encrypted Client Hello), formerly known as ESNI. ECH aims to encrypt that initial handshake segment, effectively blinding the ISP to the SNI.
While major browsers (like Firefox and Chrome) and CDNs (like Cloudflare) have begun deploying ECH, it is far from universal. For ECH to work:
- The destination website’s web server must explicitly support and configure it.
- The site’s DNS records must publish public keys via specific HTTPS/SVCB records.
If you are visiting an older server, a self-hosted corporate portal, or any site outside of top-tier modern infrastructure, your browser drops back to standard, unencrypted SNI. Your ISP is watching for that drop-back.
4. Leak #3: OCSP Stapling and Revocation Checks
Another subtle way your web security infrastructure betrays your privacy is through cryptographic certificate verification.
When you connect to an HTTPS site, your browser must verify that the site’s security certificate is valid and hasn’t been revoked due to a breach or expiration. To do this, your browser often contacts the Certificate Authority (CA) that issued the certificate using a protocol called OCSP (Online Certificate Status Protocol).
By default, many browsers send an unencrypted OCSP request to the CA asking, “Hey, is the certificate for specifichobbysite.com still valid?” Even though you used DoH to hide your original DNS lookup, your browser immediately turns around and makes a separate, plaintext outbound request regarding that specific site’s certificate. Your ISP can intercept these OCSP requests and seamlessly infer exactly where you are heading.
While OCSP Stapling (where the web server fetches its own status and “staples” it to the handshake) solves this issue, its adoption across the web is still fragmented. If a site lacks proper stapling, your browser’s background checks give you away.
5. Leak #4: Traffic Analysis and Metadata Fingerprinting
Let’s assume a hypothetical “perfect” scenario: you are hitting a website that uses a shared CDN IP, supports full Encrypted Client Hello (ECH), and uses perfect OCSP stapling. Your ISP sees nothing but an encrypted blob moving to a Cloudflare IP address. Are you safe?
Not quite. Enter Traffic Analysis.
ISPs don’t just look at strings of text inside packets; they analyze the behavior of the data streams. Every website behaves differently when it loads:
- Packet Size and Timing: A news site loads a unique sequence of text assets, CSS stylesheets, and images. This creates a distinct, recognizable sequence of packet sizes and arrival timings (a “traffic fingerprint”).
- Data Volume: Streaming a video leaves a vastly different data footprint than loading a simple text forum, even if both are fully encrypted and directed to the same CDN.
Sophisticated machine learning models can match your encrypted traffic patterns against known website fingerprints with staggering accuracy. If your ISP is motivated to track specific behaviors, encryption alone cannot alter the laws of physics governing how data moves down a wire.
Summary: The ISP Tracking Matrix
To see the big picture, consider how these protocols interact across different privacy setups:
| Security Protocol | What Your ISP Sees |
|---|---|
| HTTP (No encryption) | Everything (Full URLs, raw text data, images, passwords, cookies). |
| Standard HTTPS | Destination IP, DNS Queries, Domain Name (via SNI), and overall traffic volume. |
| HTTPS + DoH | Destination IP, Domain Name (via SNI during TLS handshake), and overall traffic volume. |
| HTTPS + DoH + ECH | Destination IP (potentially shared), Traffic Analysis/Fingerprinting, and OCSP requests. |
How to Actually Hide From Your ISP
If HTTPS and DoH aren’t enough to prevent your ISP from building a profile on you, what is? To truly blind your provider, you must break the direct link between your destination IP and your physical connection.
1. Use a Trusted Virtual Private Network (VPN)
When you use a VPN, your device creates an encrypted tunnel directly to a VPN server.
- The IP changes: Your ISP only sees the destination IP of the VPN provider, not the website you are visiting.
- The handshake is hidden: The SNI leak is contained entirely inside the encrypted VPN tunnel.
- The Catch: You aren’t eliminating the tracking problem entirely; you are simply shifting your trust from your ISP to your VPN provider. Choose a provider with a strict, audited “no-logs” policy.
2. The Tor Network
For maximum anonymity, the Tor network routes your traffic through three different volunteer-operated nodes (Entry, Middle, and Exit relays).
- Your ISP only sees that you are connected to the Tor entry node.
- They have no way of knowing what the final destination IP or website is.
- The Catch: Tor introduces significant latency and can trigger CAPTCHAs or blocks on many mainstream websites.
Conclusion: Privacy is a Multilayered Chess Match
The internet wasn’t built from the ground up with privacy as its primary directive; it was built for resilience and routing efficiency. Modern security enhancements like HTTPS and DoH are incredibly valuable tools that protect you from credential theft, session hijacking, and casual data tampering. They are vital pillars of basic digital hygiene.
However, they are not invisibility cloaks. As long as your ISP remains the physical tollkeeper of your data packets, the metadata of where you go will remain exposed unless you actively route around them. True digital sovereignty requires knowing exactly what your tools can do and acknowledging exactly where they stop short.