In brief: ECH (Encrypted Client Hello) is an IETF standard (RFC 9849, 2026) that hides the website name (SNI field) in the TLS handshake. Even with encrypted DNS enabled, your ISP can see the SNI in plaintext — ECH closes exactly that gap. The mechanism uses a "two-envelope" approach: an outer ClientHelloOuter holds a cover name belonging to a CDN, while the inner ClientHelloInner — containing the real SNI — is encrypted under the server's public key. ECH requires three conditions at once: DoH enabled, the server publishing an ECH config in DNS, and browser support. The destination IP address remains visible regardless — this is where a VPN complements ECH by hiding the entire path.
What Is ECH in Plain Terms
Encrypted Client Hello is an extension to TLS 1.3, standardised as RFC 9849 (Standards Track, IETF, 2026). Its goal is to encrypt the browser's first message to the server (ClientHello), which in standard TLS is visible to any observer on the network. That message is where the browser tells the server which specific site it wants to reach — via the Server Name Indication (SNI) field.
Think of it this way: when you post a letter, the address on the envelope is visible to everyone who handles it. DoH encrypts the directory (DNS), so the carrier no longer knows which IP you're looking up. But the envelope itself with the address (SNI) is still open — the postman (your ISP) can read it. ECH places your real envelope inside a second outer one bearing a different, "cover" address. Only the recipient (the server) has the key to open the outer envelope and retrieve the real one inside.
ECH's predecessor was ESNI (Encrypted SNI), which appeared around 2018 and encrypted only the SNI field. ESNI became obsolete around 2020: it had cryptographic limitations and didn't cover other sensitive ClientHello fields — notably ALPN (application protocol negotiation). ECH encrypts the entire ClientHello and is fully compatible with TLS 1.3.
What Problem ECH Solves: The SNI Leak
What SNI Is and Why It's Visible
When a browser establishes an HTTPS connection, the first message — ClientHello — contains the SNI (Server Name Indication) field. Servers and CDNs need it to serve multiple domains from a single IP address. In standard TLS, this field is transmitted in plaintext before encryption is established. Your ISP, a corporate firewall, or any observer "on the path" sees SNI as clearly as a URL in the address bar.
SNI is the primary source of metadata about visited websites under HTTPS. Page contents are encrypted, but the site name is not. DPI (Deep Packet Inspection) systems exploit exactly this field for ISP-level traffic analysis.
Why Encrypted DNS (DoH) Is Not Enough
Encrypted DNS (DoH/DoT) hides DNS queries — your ISP stops seeing which IP you're requesting for a domain. Without DoH the site name leaks twice: in DNS and in SNI. DoH closes the DNS leak, but the SNI in the TLS handshake remains exposed regardless of how you obtained the IP address. With DoH enabled, your ISP no longer sees the DNS query — but moments later it sees the ClientHello with SNI: example.com in plaintext.
As covered in our article on what your ISP can see, SNI is the last open identifier that persists even after DNS is encrypted. ECH closes it.
What a network observer sees at different protection levels:
| What the observer sees | Standard HTTPS | +DoH | +DoH & ECH | VPN |
|---|---|---|---|---|
| DNS query (site name) | Visible | Hidden | Hidden | Hidden |
| SNI (site name in TLS) | Visible | Visible | Hidden | Hidden |
| Destination IP address | Visible | Visible | Visible | Only VPN server IP visible |
| Connection fact | Visible | Visible | Visible | Visible (to VPN server) |
How ECH Works: ClientHelloOuter and ClientHelloInner
ECH's mechanism is built on the "two-envelope" concept and uses HPKE (Hybrid Public Key Encryption) — a modern asymmetric encryption scheme designed specifically for this purpose.
When a browser opens a site with ECH, it constructs two ClientHello messages. ClientHelloOuter is the outer, fully visible one: its SNI field holds a "cover" name, typically belonging to a CDN or shared frontend (for instance, a Cloudflare domain). This is what the ISP sees — nothing else. ClientHelloInner is the inner message: it contains the real SNI of the target site, the ALPN field (HTTP/2, HTTP/3), and other TLS negotiation parameters. ClientHelloInner is encrypted under the server's public ECH key using HPKE.
The server publishes its ECH public key in advance in a DNS record of type HTTPS (or SVCB). The browser retrieves this key via DoH — which is exactly why DoH is mandatory: without it the browser cannot safely obtain the encryption key. The server decrypts ClientHelloInner with its private key and reads the real SNI. The network observer sees only the ClientHelloOuter with the CDN cover name.
Note: HPKE is an asymmetric encryption scheme at the TLS-handshake level, aimed solely at protecting the ClientHello. It is not a VPN cipher (not ChaCha20, not AES). The rest of the connection is encrypted by standard TLS 1.3 — exactly as without ECH.
What You Need for ECH to Work
ECH is a composite technology: if any single component is missing, the browser does not apply ECH and the connection proceeds normally — no error, just no SNI encryption. Three mandatory conditions:
- Encrypted DNS (DoH or DoT) must be enabled. The ECH config is published in a DNS HTTPS/SVCB record and the browser fetches it during name resolution. Without encrypted DNS, the public key could be tampered with — defeating the purpose of ECH.
- The server or CDN must publish an ECH config in DNS. The HTTPS/SVCB record must contain an
ech=field with the public key. This is why Cloudflare-hosted sites support ECH more broadly: Cloudflare enables ECH configs for hosted domains at the CDN level. - The browser must support ECH. Firefox has ECH enabled by default since version 119. In Chrome/Chromium, ECH must be manually enabled via experimental flags. Most Chromium-based mobile browsers (Chrome for Android) don't use ECH by default.
If any condition is unmet, the browser sends a standard ClientHello — "ECH fallback". The connection establishes normally; SNI remains exposed.
How to Enable ECH in Your Browser
Firefox
ECH has been enabled by default in Firefox since version 119. No extra configuration is needed. The key requirement is that DoH must be active: without it the browser cannot retrieve the ECH config from DNS.
To verify: open about:config → search for network.dns.echconfig.enabled — it should be true. For DoH: Settings → General → Use DNS over HTTPS. Choose "HTTPS-Only" mode to ensure the browser never sends DNS queries in plaintext when the DoH server is unreachable.
Since Firefox 129, the browser can also retrieve HTTPS records via the system DNS resolver if it supports DoH at the OS level — simplifying setup on corporate devices.
Chrome / Chromium / Brave
In Chrome and Chromium-based browsers, ECH is not enabled by default (as of 2026 in the stable channel). To enable it manually:
- Open
chrome://flagsin the address bar. - Search for
#encrypted-client-helloand set it to Enabled. - Search for
#use-dns-https-svcb-alpnand also set it to Enabled — without this the browser won't request the HTTPS/SVCB DNS record containing the ECH config. - Click Relaunch to restart the browser.
- Confirm DoH is active: Settings → Privacy and security → Security → Use secure DNS.
In Brave, enable ECH via brave://flags/#encrypted-client-hello. Brave does not activate ECH by default, though its built-in DoH satisfies the first condition.
How to Verify ECH Is Working
After enabling ECH and DoH, confirm the browser is actually applying ECH. Cloudflare provides an ECH check page — search for "ECH check Cloudflare" or "ECH test browser". Browserleaks.com also reports TLS connection parameters including ECH status.
ECH and VPN: The Difference and Why You Want Both
ECH and VPN are fundamentally different tools with different scopes. ECH encrypts one specific field in one TLS handshake message — and only for sites that support ECH. Your ISP can still see the IP you're connecting to, the fact and volume of the connection, and for sites without ECH support, the SNI as well.
VPN operates at a different level: it wraps all device network traffic in an encrypted tunnel. Your ISP sees only a connection to the VPN server's IP — DNS queries, SNI, and destination IPs are all hidden. This covers every site and app regardless of ECH support.
ECH doesn't work everywhere: it's powerless against sites without an ECH config in DNS. VPN adds latency and requires trusting your provider — choose a reliable no-logs VPN that keeps no connection logs. The ideal setup combines both: VPN hides the IP and all traffic, ECH additionally encrypts SNI inside connections where it's supported.
Practical rule: when VPN is active, SNI inside the encrypted tunnel is already hidden from your ISP. ECH is most valuable as a standalone tool — when VPN is off or not configured on a particular device. See our article on how VPN protects from ISP tracking for a detailed breakdown of what metadata a VPN hides.
Checklist: How to Stop Your Site Name from Leaking
- Enable DoH in your browser. Firefox: Settings → General → DNS over HTTPS (choose HTTPS-Only). Chrome: Settings → Privacy → Secure DNS.
- Confirm ECH is active in your browser. Firefox v119+: on by default. Chrome/Brave: enable via
chrome://flags→#encrypted-client-hello. - Keep your browser up to date. ECH support improves with every release; an outdated browser is guaranteed to lack ECH.
- Test ECH on a dedicated check page. Enabling the flag alone isn't enough if DoH isn't working — verify ECH is actually being applied.
- Use a VPN on public networks. ECH doesn't hide destination IPs and offers no protection for sites without ECH configs. A VPN covers all traffic entirely.
- Check for DNS leaks. Even with DoH and ECH, some browsers may route certain queries through unencrypted system DNS.
- On mobile — configure DoH at the system level or use an app with built-in DoH. Most mobile browsers don't enable ECH by default; a VPN with DoH on board is a practical alternative.
ECH Limitations: What You Should Know
The destination IP address remains visible. Even with ECH, your ISP sees which IP you connected to. An IP can often identify a CDN or specific site — especially for small sites with dedicated IPs. ECH hides only the SNI field; it doesn't conceal the recipient at the network layer.
It only works where the server supports it. If a target site has no HTTPS record with an ECH config in DNS, the browser doesn't apply ECH. The majority of sites don't support it yet — ECH is most common on Cloudflare-hosted sites and a few other major CDNs.
Some networks may block or degrade ECH. Aggressive corporate proxies, DPI filters, or outdated network equipment may block HTTPS records in DNS or interfere with the ECH handshake. The browser falls back to standard ClientHello — the connection still works, just without SNI encryption.
WebRTC IP leaks are unrelated to ECH. ECH protects only the SNI field in the TLS handshake. Browser leaks via WebRTC or other vectors are outside ECH's scope.
Frequently Asked Questions
Is ECH the same as a VPN?
No. ECH encrypts the SNI field in the TLS handshake at supporting servers — targeted protection of one metadata item. A VPN encrypts all device traffic and hides destination IPs. They solve different problems and complement each other.
Do I need ECH if I already use a VPN?
Inside a VPN tunnel the SNI is already hidden from your ISP. ECH is most useful when VPN is off — at home on a trusted network, or on a device without a VPN app. Enabling both doesn't hurt.
Does ECH slow down my internet?
Practically no. ECH is part of the standard TLS handshake that happens on every HTTPS connection anyway. The added HPKE cryptography introduces no noticeable latency.
Does ECH work on all websites?
No — only where the server or CDN has published an ECH config in an HTTPS/SVCB DNS record. On sites without such a record, the browser sends a standard ClientHello with SNI in plaintext.
Can my ISP still see my IP address when ECH is enabled?
Yes, the destination IP remains visible with any direct connection. ECH hides only the SNI. To hide the destination IP, use a VPN.
How is ECH different from ESNI?
ESNI (2018–2019) encrypted only the SNI field and had cryptographic limitations. ECH (RFC 9849) encrypts the entire ClientHello using HPKE and is fully compatible with TLS 1.3.
Is it safe to enable ECH?
Yes. ECH is a ratified IETF standard (RFC 9849). If the server doesn't support it, the browser silently falls back to standard TLS — no security is lost.