What Your HTTPS Connection Still Leaks: SNI, Fingerprints, and ECH
HTTPS encrypts the page, not who you're talking to. The metadata that survives encryption — DNS, destination IP, and the cleartext SNI — who reads it, how TLS fingerprinting identifies your client even when names are hidden, and what Encrypted Client Hello actually changes.
There's a comfortable myth that "it's HTTPS, so it's private." HTTPS does one job extremely well: it encrypts the contents of your request and response. What it does not do is hide who you're talking to. On any network you don't control — a café hotspot, a corporate proxy, your ISP, a hotel gateway — a passive observer can still learn a surprising amount about your browsing without decrypting a single byte.
This piece walks the actual bytes on the wire: what survives encryption, who can read it, how fingerprinting identifies your client even when names are hidden, and what Encrypted Client Hello (ECH) really changes. The threat model throughout is the ordinary one — anyone sitting on the network path between you and the site.
By the end you'll understand:
- The three things that leak on every HTTPS connection: DNS, destination IP, and the cleartext SNI
- Why the hostname you visit is broadcast before encryption starts — and who logs and filters on it
- How JA3/JA4 fingerprint your TLS client even with the name hidden, and why a bespoke stack is a tracking beacon
- What ECH actually does, what it needs to work, and what it still doesn't protect
We do this kind of work for hire.
Network architecture review, self-hosted privacy stacks, zero-trust corporate VPNs.