HTTPS over TLS 1.3 encrypts the certificate, the URL path and the page. The site's name still goes out in plain text, in a field called Server Name Indication (SNI) inside the very first message, the ClientHello. Your ISP can read it, and so can a café's Wi-Fi or a corporate firewall. SNI encryption closes that gap, and Encrypted Client Hello (ECH) is the standard that does it: RFC 9849, published in March 2026.
ECH hides which site you asked for. It does not hide where the connection goes, or the DNS lookup that came before it.
How SNI encryption works in ECH
The browser builds two hellos. The inner one carries the real name and the real ALPN list (the protocols it offers, such as HTTP/2 and HTTP/3) and is encrypted with a public key the site published in DNS. The outer one travels in plain text with a stand-in name.
- The browser asks DNS for the site's HTTPS record, a record type that describes how to connect. If the record has an ech parameter, it holds the public key and the stand-in name, called the public_name.
- The browser encrypts the inner ClientHello to that key.
- It sends the outer ClientHello with the public_name in the SNI field and the encrypted inner one attached as an extension.
- The server decrypts the inner hello and finishes the handshake as the real site. If the key is stale or the server doesn't speak ECH, it answers as the public_name and, when it can, hands back fresh keys so the browser retries.
Sites behind the same provider that share a key and look alike on the wire form an anonymity set. An observer sees a connection to the provider and can't tell which of its sites it was.
Who sees what
What an ISP, a Wi-Fi owner or a firewall on the path can read:
| What a network observer reads | No ECH, plain DNS | ECH, plain DNS | ECH, encrypted DNS |
|---|---|---|---|
| Site name in the SNI field | Readable | Hidden | Hidden |
| Real ALPN list | Readable | Hidden | Hidden |
| Site name in the DNS lookup | Readable | Readable | Hidden |
| Destination IP address | Readable | Readable | Readable |
| Provider's public_name | Not used | Readable | Readable |
| Packet sizes and timing | Readable | Readable | Readable |
| URL path, cookies, page content | Hidden | Hidden | Hidden |
The DNS resolver sees every name it resolves in all three setups, and the destination can read the real name, so both always know.
What stays visible with ECH
- The IP address. A connection has to reach a server, so the address is on the wire. When thousands of sites share a provider's addresses it says little. A site alone on its own address is identified by that address, and ECH adds nothing there.
- The public_name. Every ECH site at a provider shows the same stand-in, such as cloudflare-ech.com on Cloudflare. It tells an observer which provider the connection goes to, and a fixed name is easy to match. In November 2024 Russia began blocking connections that carry an ECH extension together with that visible name. Browsers also send a decoy ECH extension to sites without ECH, so the extension alone gives nothing away; the name does.
- Volume and timing. ECH pads the inner hello (the configuration carries a maximum_name_length for that) so its size doesn't hint at the name. The size and rhythm of the traffic after the handshake are another matter and remain visible.
- The rest of the outer hello. Cipher suites, extensions and their order are in plain text, and a TLS fingerprint such as JA4 is built from fields like these. They describe the client software, not the site.
Encrypted Client Hello and DNS
The key for ECH lives in DNS, so DNS both delivers the key and leaks the name. With plain DNS, the lookup for the site and for its HTTPS record cross the network readable, which gives the name away before the handshake starts. A network that controls the answers can also delete the ech parameter. The browser then has no key and connects the old way, with the name in plain text. Once it holds a key, it doesn't quietly retry with a plain hello when the handshake fails, so a network that wants the name must remove the key beforehand or block the connection. Encrypted DNS (DoH, DoT or DoQ) closes the first two holes on the path, though the resolver you picked still sees every name.
ECH vs VPN
A VPN and ECH hide different things from different observers. A VPN tunnels all traffic, so the local network sees only the VPN server, and the VPN provider takes the observer's seat, seeing destination addresses plus any names in handshakes and DNS queries that aren't encrypted. ECH removes the name from the handshake, so that observer can't read it there, though the addresses remain. Together they split the job: the VPN hides the destination addresses from your ISP, and ECH hides the handshake name from the VPN provider.
Where ECH is switched on in 2026
- Chrome has had ECH on by default since version 117 (September 2023), Firefox since October 2023.
- Android 17 adds ECH at the platform level and pairs it with Private DNS, the system-wide encrypted DNS setting. Apps need a networking library that uses it: OkHttp 5.5.0 and later can enable it, the system HttpEngine follows in Android 17 QPR2 and WebView in a later release.
- OpenSSL 4.0, released in April 2026, is the first OpenSSL release with ECH, so software that builds on it can start supporting ECH.
- Cloudflare enables ECH by default on Free zones; other plans turn it on in the dashboard. Most domains that support ECH sit behind Cloudflare, so most of the anonymity set is one company's network.
What filters and firewalls do about ECH
A filter that matches on the SNI loses its input once the name is encrypted. Filtering by name still works at the DNS resolver, which sees every name. Where that doesn't fit, a network can answer HTTPS queries without an ech parameter, or not at all, so clients never get a key. Managed browsers can switch ECH off: Chrome has an enterprise policy for it, and Firefox stops using ECH when the resolver returns no answer for a canary domain. The last resort is decrypting the traffic at a TLS-intercepting proxy.
Check a site and your own connection
- The ECH Checker looks up a domain's HTTPS record, reads the ech parameter and decodes the configuration, including the public_name that observers see. A domain with no ech parameter gives a browser no key to encrypt with, whatever the browser supports.
- The ECH Status card on the Privacy & Trust Index reports whether the name of the site you visited was encrypted in your connection. When the name was hidden but your DNS still reveals it, the card says DNS STILL OPEN.
- Browser switches and server settings are in the ECH setup guide.
Top comments (0)