What HTTPS Actually Hides From Your ISP (And What It Doesn't)

The Padlock Solves One Specific Problem

When your browser shows the padlock, what is actually happening is a TLS connection to the server. The TLS handshake negotiates an encryption key, then both sides use it to encrypt the rest of the conversation. MDN summarizes the three guarantees: "the data exchanged between client and server is encrypted while in transit, so it can't be read by any attackers," the connection has integrity so "an attacker can't secretly modify data (without detection) while it is in transit," and the server proves it is who it claims to be via its certificate.^[1]

Translated into what a network observer sees:

• The exact URL path you requested: encrypted.
• The cookies your browser sent: encrypted.
• The HTML, JSON, image, and file bodies the server sent back: encrypted.
• The Authorization and Cookie headers: encrypted.

For an attacker sniffing the coffee shop Wi-Fi or a state-level passive collector tapping the backbone, the payload of an HTTPS connection is opaque. That is the win the padlock represents.

What HTTPS Does Not Hide From the ISP

Four pieces of information stay visible to your ISP (or anyone else on the network path) even when the padlock is showing. None of them require breaking the encryption.

1. The destination IP address

To send a packet anywhere, your router needs an IP address to send it to. That IP address is in the clear at the IP layer, below TLS, in every packet leaving your device. Your ISP routes the packet based on that address. The same address is visible to every router in between and to every backbone operator along the path. TLS does not, and structurally cannot, hide the destination IP, because the packet has to be routable before it can be delivered.^[1]

The IP address alone is often enough to identify the site. Most large websites share hosting on a small number of cloud front-ends (Cloudflare, Fastly, Amazon CloudFront, Akamai, Google, Microsoft). A connection to one of those IPs is almost certainly a connection to a customer of that provider, and the customer base is small enough to enumerate.

2. The Server Name Indication (SNI) in the TLS handshake

Even before TLS encryption starts, the browser has to tell the server which certificate to present, because one server may host thousands of sites. It does this with the Server Name Indication extension, defined in RFC 6066, which states that "HostName contains the fully qualified DNS hostname of the server, as understood by the client."^[2] SNI rides in the cleartext ClientHello message. RFC 8446 (TLS 1.3) confirms that the SNI extension travels in the ClientHello, listed in the extensions table for "CH, EE" (client hello, encrypted extensions).^[3] The Cloudflare engineering blog puts it bluntly: "Sending the SNI in plaintext means that any intermediary can view which website you're visiting simply by checking the first packet for a connection."^[4]

So even though the contents of the page are encrypted, the very first packet of an HTTPS connection tells the ISP the name of the site you are about to load. Combine that with the destination IP and your ISP has a clean log of every HTTPS site you visit, every day, with no need to crack anything.

3. The DNS lookup (unless you use DoH or DoT)

Before your browser can open a TLS connection at all, it has to look up the site's IP address. By default, that lookup goes over plain DNS on UDP port 53, in cleartext, to a resolver run by your ISP. Your ISP sees every hostname you resolve, in order, before the encrypted connection even starts. RFC 8446 lists SNI in the ClientHello, but it cannot address DNS, which happens earlier and below TLS entirely.^[3]

The fix here is DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT). Cloudflare's DoH documentation explains: "DNS over HTTPS (DoH) encrypts DNS queries by wrapping them inside regular HTTPS requests."^[5] Mozilla, Google, and several other providers offer DoH, and most major browsers can be configured to use it. But until you turn DoH on, the ISP sees the DNS lookup regardless of how good your HTTPS is.

4. The connection's TLS version, cipher suite, and traffic shape

The TLS handshake is the first packet flight on a connection, and the handshake itself runs in the clear. The ClientHello advertises the cipher suites and TLS versions your browser supports, and the ServerHello picks one. These are visible to the network observer.^[3] The length of the encrypted records, their timing, and their direction are also visible. None of these alone identifies a specific page, but a determined observer can fingerprint sites by combining them with the destination IP and SNI.

What Your ISP Can Build From the Visible Pieces

Treat your ISP as an adversary who sees:

• Your account-level identity (the IP your router was assigned).
• The DNS hostname you resolved and when.
• The destination IP you connected to and when.
• The SNI hostname in the TLS ClientHello and when.
• The encrypted payload sizes and timing.

That is more than enough to build a complete list of every site you visited, how long you were on it, and how often you visit. The list can be sold, shared with law enforcement under a pen register order, or kept indefinitely under data-retention laws. The contents of the pages you read are still opaque, but the behavioral record is detailed. That is what HTTPS alone does not protect.

What Actually Closes the Gap

Three layered fixes, in order of how much they close the visibility gap.

DNS-over-HTTPS or DNS-over-TLS

Encrypts the hostname lookup, so the ISP can no longer see the DNS query in cleartext. Cloudflare's DoH documentation notes that DoH "encrypts DNS queries by wrapping them inside regular HTTPS requests" and that DoH "sends DNS traffic over port 443," which makes the queries "difficult to distinguish from other HTTPS traffic on the network."^[5] Most current Firefox, Chrome, Edge, and Brave releases support DoH. Your operating system also has its own DoH setting in network settings; on Android, the "Private DNS" option under network settings is DoT, not DoH, but it does the same job.

Encrypted Client Hello (ECH)

ECH is the TLS 1.3 extension that encrypts the SNI, so the ISP can no longer see the hostname in the cleartext ClientHello. Cloudflare's deployment writeup describes the design: ECH "encrypts the full handshake so that this metadata is kept secret. Crucially, this closes a long-standing privacy leak by protecting the Server Name Indication (SNI) from eavesdroppers."^[4] After ECH is enabled on both ends, an observer sees only the client-facing server, not the specific origin behind it. ECH is rolling out in Firefox and Chrome, and Cloudflare offers it across all free zones.^[4]

A real VPN or Tor

A VPN or Tor is the only thing that hides the destination IP address from your ISP, because your packets never go to the destination at all; they go to the VPN exit or Tor relay. Once your ISP sees only an IP belonging to your VPN provider, it can no longer tell which site you visited. The trade-off is that the VPN provider (or the first Tor relay, in Tor's threat model) now sees the same metadata your ISP used to see. This is a real trade-off, and the choice of provider matters. Tor is stronger than a typical commercial VPN because no single relay sees both your IP and the destination.

The Honest Scorecard

Read across the rows. HTTPS alone hides the content, not the destination. Adding DoH/DoT hides the DNS lookup. Adding ECH hides the hostname in the TLS handshake. Only a VPN or Tor hides the destination IP from your ISP, at the cost of moving the same visibility to a different party.

What To Actually Do

• Turn on DNS-over-HTTPS in your browser. In Firefox, Settings → Privacy & Security → scroll to "Enable secure DNS using HTTPS." In Chrome, Settings → Privacy and security → Security → "Use secure DNS." Choose a resolver you trust (Cloudflare, Quad9, Mullvad, or your ISP's own DoH endpoint if you want them to still see it).
• Turn on Private DNS on Android. Settings → Network & internet → Private DNS → "Private DNS provider hostname." Put one.one.one.one for Cloudflare or dns.quad9.net for Quad9. This is DNS-over-TLS, same protection as DoH for the lookup.
• Check whether your browser has ECH turned on. In Firefox, type about:config and search for network.dns.echconfig.enabled; the default is true. In Chrome, type chrome://flags#encrypted-client-hello. ECH only works when both browser and server support it, which is most major Cloudflare-fronted sites today.
• If you actually want your ISP blind, use a VPN or Tor. Pick a provider whose trust you have independently verified (independent audits, a published warrant canary, jurisdiction outside Five Eyes). Tor is the right answer if anonymity matters more than speed. Either of these trade your ISP's visibility for a different party's visibility, so choose accordingly.

Related Coverage

• VPN vs Incognito Mode: They Are Not the Same Thing
• VPN vs Tor vs Proxy: Which Do You Need?
• Secure DNS: DoH and DoT Setup Guide
• VPN Strategy: Choosing the Right Provider
• What Your ISP Actually Knows About You
• Browser Privacy Settings
• The full guides hub

Sources

1. MDN Web Docs: Transport Layer Security (TLS)
2. IETF RFC 6066: Transport Layer Security (TLS) Extensions, Section 3 (Server Name Indication)
3. IETF RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3, Section 4.1.2 (ClientHello)
4. Cloudflare Blog: Announcing Encrypted Client Hello (ECH)
5. Cloudflare Docs: DNS over HTTPS (DoH)