When your browser opens a TLS connection to example.com, the very first packet — the ClientHello — includes a Server Name Indication (SNI) extension that names the host you're trying to reach. The reason SNI exists is practical: one IP address routinely hosts hundreds or thousands of TLS-terminated sites, and the server needs to know which certificate to present before the handshake can proceed. So the client tells it, in plaintext, before any encryption is set up.
That plaintext field is the last meaningful leak in modern TLS. Anyone watching the network — your ISP, the coffee-shop Wi-Fi, a national firewall, a corporate middlebox — can read it and learn which sites you visit, even if they can't read what you exchange there. TLS 1.3 tightened almost everything else. SNI was left for a follow-up specification.
That follow-up is Encrypted Client Hello (ECH), currently at draft 24 in the IETF and increasingly deployed in the wild.
What ECH Actually Does
ECH wraps the sensitive parts of the ClientHello — including the real SNI — in a public-key encryption envelope before sending it. The wire packet still has an SNI field, but it names a generic public hostname owned by the front-facing server, not the actual site you're requesting.
The real flow looks like this:
- The client looks up the server's ECH public key. (Today this is done via a DNS HTTPS RR — itself fetched over DNS-over-HTTPS for it to be meaningful.)
- The client builds an "inner" ClientHello with the real SNI and sensitive extensions, then encrypts it with HPKE (RFC 9180) using the server's ECH key.
- The client wraps that inner hello inside an "outer" ClientHello whose SNI is the generic frontend hostname.
- The server decrypts the inner hello, switches context to the real backend hostname, and completes the handshake using the real certificate.
Hybrid Public Key Encryption (RFC 9180) is the modern, standardized way to encrypt a small payload to a known public key — used by ECH, MLS, and a growing list of other protocols where you need authenticated encryption to a recipient you can't do a full handshake with.
What an Eavesdropper Sees, With and Without ECH
| Field | Without ECH | With ECH |
|---|---|---|
| Destination IP | Visible | Visible |
| Outer SNI (in ClientHello) | Real hostname | Generic frontend hostname |
| Server certificate | Plaintext (TLS 1.2) / encrypted (TLS 1.3) | Encrypted |
| Real hostname requested | Visible | Encrypted |
| DNS lookup for hostname | Visible unless DoH/DoT | Visible unless DoH/DoT |
Notice what ECH does not hide: the destination IP, and the DNS lookup that produced it. ECH only protects the TLS handshake itself. If your DNS resolver leaks the lookup, or if the destination IP is uniquely associated with the target site, the privacy gain is reduced. ECH is meaningful primarily when many domains share an IP — which is exactly the world large CDNs have created.
Why CDNs Are the Real Story
ECH only meaningfully hides which site you're visiting if the destination IP is ambiguous — that is, if it serves many possible sites. That's the deployment reality on Cloudflare, Fastly, Akamai, and other CDNs that already terminate TLS for huge swaths of the web. When a single Cloudflare IP fronts ten thousand domains, a network observer who sees you connecting to that IP learns: "this user is talking to one of ten thousand Cloudflare sites." ECH then prevents narrowing it further during the handshake.
For sites that run on dedicated IPs, ECH provides much less. The destination IP itself effectively names the site.
Why Deployment Was Slow
ECH had a long, painful gestation. An earlier version (ESNI, encrypted SNI) was deployed by Cloudflare and Mozilla as far back as 2018, then withdrawn when the working group consolidated around the more general ECH design. ECH itself spent years at draft, partly because it had to handle a thorny edge case: graceful failure when network elements actively interfere with ClientHello packets they don't understand.
Some national firewalls began blocking ECH traffic outright in 2024 once Chrome and Firefox started enabling it on Cloudflare-fronted sites — illustrating both that the technology was effective and that defenders need a Plan B for hostile networks. The IETF's response has been to standardize fallback behavior carefully so that ECH degrades to plain TLS rather than failing the connection entirely.
Browser and Server Support, Today
- Chrome: ECH enabled by default since 2024, gated on the server publishing the right DNS record.
- Firefox: Enabled by default since version 119 (2023), uses DNS-over-HTTPS to fetch the key.
- Safari: Adoption has lagged; rolling out gradually as of 2026.
- Cloudflare: Supports ECH on most zones, opt-in per account.
- Nginx / Caddy / Apache: Patchwork; full ECH support depends on the underlying TLS library version (OpenSSL 3.5+ and BoringSSL added stable APIs in late 2025).
The Trade-Off Nobody Likes to Mention
ECH protects against passive network observers — but it concentrates trust. The CDN or front server still sees which real site you asked for, because it decrypts your inner hello. So ECH meaningfully hides your destination from your ISP and intermediate networks, while shifting that visibility to the front-server operator.
For most people this is a substantial win: your ISP is a known surveillance choke point, while a CDN at least has a published privacy posture. For threat models that explicitly distrust the CDN, ECH doesn't help — you need different infrastructure (Tor, a self-hosted egress, etc.).
Encryption pushed end-to-end nearly everywhere, then stopped at the hostname. ECH finally closes that gap — but it closes it by handing the secret to whoever you've already chosen to trust with your traffic. That's not a downside; it's just honest accounting.
What Users Can Actually Do
- Use a browser with ECH enabled (Firefox 119+, recent Chrome).
- Use DNS-over-HTTPS or DNS-over-TLS. Without encrypted DNS, ECH's protection is diminished — the lookup for the hostname leaks the name your TLS handshake just hid.
- Prefer sites on large multi-tenant CDNs. The privacy benefit of ECH scales with the size of the anonymity set behind a single IP.
- For high-risk threat models, layer. ECH does not replace Tor or a trusted VPN for hiding which sites you visit from a determined adversary. It's a hardening of the baseline, not a circumvention tool.
Where Haven Fits
Haven's web frontend is fronted by Cloudflare, which supports ECH. For users on modern browsers with DoH enabled, the TLS connection to havenmessenger.com is fully metadata-protected at the network layer — observers learn you connected to Cloudflare, not specifically to us. Combined with our application-layer encryption (PGP for email, MLS for chat), this brings the leakable network metadata about Haven usage close to its theoretical minimum on the open internet.