What Encrypted Traffic Still Reveals

I built the network monitoring for a product I run, and when I decided what it should record, I settled on domains and nothing else. Not the pages anyone visited, not what they typed, not what came back. Just the names of the services each device connected to, and when.

That was less restraint than a technical fact. The domain was the part I could see. The page addresses and the contents were encrypted and simply not available from where I was sitting.

That split is what most people have backwards about HTTPS. They hear encrypted and picture a sealed envelope. What you actually have is a sealed envelope with the address written on the outside in large clear handwriting, handed to a courier who reads every address they carry.

What is genuinely inside the envelope

The path is encrypted. Visit a specific page deep inside a site and that address is protected. So is the query string, meaning search terms, parameters, identifiers. So is everything you send: form data, passwords, messages, uploads. And the entire response coming back, page and images alike.

Someone watching the wire sees encrypted bytes for all of it. That protection is real and it is why HTTPS was worth deploying everywhere.

What is not encrypted is which service you are talking to, and that leaks in three separate places.

Leak one: DNS

Before your device connects to anything it turns a name into an address by asking a resolver. Classically that question and answer travel in plaintext, so anyone between you and the resolver reads the name.

This is the best known leak and the most successfully addressed. DNS over HTTPS and DNS over TLS both encrypt that exchange, and if you have enabled either, or your browser did it quietly on your behalf, this one is largely closed.

Leak two: SNI, the one people miss

Server Name Indication lives in the TLS handshake itself.

It exists for a practical reason. One server IP commonly hosts many different websites, which is how shared hosting and CDNs work. When your device opens a connection and asks to start an encrypted session, the server holds certificates for hundreds of sites and must know which to present before encryption exists. It cannot ask you afterwards, because the encryption has to be established first.

So the client announces it up front. In the very first message of the handshake, before any encryption, your device states the hostname it wants, in the clear. That happens on essentially every HTTPS connection you make.

Walking one connection through in order makes it click. Your device asks a resolver for an address, readable unless you use encrypted DNS. It opens a connection to that address, visible because it must be routed. It sends the first TLS message carrying the hostname in plaintext. Only after the handshake completes does anything become encrypted.

By the time protection switches on, the observer already has the name, the address, and the timestamp. The encryption arrives after the identifying part has gone past.

That ordering is not an oversight. It follows from needing to agree which certificate to use before you can have a secure channel in which to agree. You cannot negotiate privately until you have negotiated, and the negotiation must name the destination.

There is a fix worth knowing by name: Encrypted Client Hello, or ECH. It wraps that first message so the hostname stays hidden. Real, deployed, and supported by several large providers. But it needs support at both ends plus a DNS record to bootstrap, so coverage is partial. It helps where available and is not something to assume protects you everywhere.

Leak three: the address itself

No protocol fixes this one. Packets must be routed somewhere, so even with the name fully hidden, the destination address is visible to everyone carrying them.

How much that gives away depends on who is at that address. A large shared CDN with millions of sites behind it is genuinely ambiguous. A small service on its own server is identified exactly, and no encryption changes that. The privacy you get from hiding a name is partly a function of how much company that server keeps.

Traffic analysis, which is not quite a leak

Even unable to read anything, an observer sees the shape: how many bytes moved, in which direction, with what timing.

Different activities have different shapes. Streaming video is a large sustained download with a particular rhythm. A voice call is a steady stream of small packets in both directions. Loading a page is a burst then quiet. A short message is a blip.

So someone can often tell what kind of thing you are doing without decrypting a byte. The techniques improve over time. For the ordinary case I would rank it below the domain leak, because it takes more effort and yields fuzzier answers, but it is why “they cannot see anything” is too strong.

Mobile is a broader picture

A carrier carrying your data sees the same domain-level list anyone on the path would. But it also holds things no cafe router could, because being a phone network requires them.

Which tower your device is attached to, meaning roughly where you are, continuously, for as long as the phone is on. Which SIM is doing it, tied to whatever identity documents registered it. Call and message records that have nothing to do with internet traffic.

So on mobile the browsing metadata is one stream joined to a location trail and a verified identity. None of that is affected by anything you do at the application layer. Encrypted DNS does not touch it. Neither does ECH. All of it follows from how the network locates your device in order to deliver anything at all.

What the record actually describes

Anyone on the path gets a list: this device, at these times, connected to these services, moving roughly this much data. No page addresses, no contents.

That reveals more than people assume. The set of domains you connect to describes which bank you use, which health services you look at, which messaging and dating apps are on your phone, whose systems you log into, and roughly when you wake and sleep based on when your phone starts talking.

It also tends to be retained rather than glanced at and discarded. Connection logs are kept for varying periods depending on who holds them and the rules they operate under. So the question runs past who can see this today. Who still holds it in a year, and who can ask them for it? A snapshot feels harmless in a way a searchable history does not.

A VPN moves the observer, it does not remove them

With a VPN, your local network and ISP see one encrypted connection to the provider and nothing about its contents. That is a genuine improvement if your concern is cafe wifi or your carrier.

But the VPN provider now sits exactly where your ISP used to sit, and sees exactly what your ISP used to see. Every domain, every connection.

So a VPN answers a narrower question than the marketing suggests: who does the seeing. That is a real question with a real answer sometimes. On a hostile network, or when your carrier is the specific party you are worried about, shifting visibility to a provider you chose is a reasonable trade. It is a trade, not an erasure, and marketing that implies otherwise is selling you something.

What actually helps

Turn on encrypted DNS. It is usually one setting and it closes the easiest leak.

Enable Encrypted Client Hello where your browser offers it, understanding it only works when the other end cooperates.

Prefer services that keep company on large shared infrastructure, since a destination shared with millions is less informative than one that is not.

And if you genuinely need the destination hidden from everyone on the path, Tor is the tool built for that specific problem, at a real cost in speed. It is a different tool from a VPN, not a stronger one.

What does not help is assuming the padlock means invisibility. It means the contents are protected in transit. It never meant the destination was hidden, and was never designed to.

Two limits on the above. I am describing what is visible from the network path, which is what I can speak to from having built a capture that sits there. I am not covering what the service at the other end knows about you, which is separate and usually a much larger exposure, since they see everything by definition. ECH deployment also keeps moving, so anything specific about coverage is a snapshot.

The model to leave with is the envelope. Contents sealed, address visible, courier taking notes.

If you want more breakdowns like this on how everyday identifiers get tracked and what actually limits that, you can find the rest of our explainers at The Privacy Wire.