How Encrypted Client Hello Protects Your Browsing Privacy

What Is Encrypted Client Hello and Why Does It Matter?

Encrypted Client Hello (ECH) is a TLS extension that encrypts the Server Name Indication (SNI) field in your browser’s initial handshake with a website, hiding which specific site you’re visiting from anyone monitoring your connection. Without ECH, your ISP, network admin, or any on-path observer can read the SNI in plaintext — meaning they know exactly which domain you requested, even when the rest of your HTTPS traffic is fully encrypted. Encrypted Client Hello ECH explained in simple terms: it closes the last major metadata leak in the TLS handshake.

The TLS Handshake Problem: Why SNI Leaks Your Browsing History

Every time your browser connects to a website over HTTPS, it performs a TLS handshake. During that handshake, your browser sends a “Client Hello” message to the server. This message includes the Server Name Indication (SNI) — a plaintext field that tells the server which domain you want to reach.

The SNI exists for a practical reason: many servers host multiple websites on the same IP address. Without the SNI, the server wouldn’t know which TLS certificate to present. But this creates a significant privacy gap.

What the Client Hello Exposes

• SNI field — The exact domain name you’re visiting (e.g., mail.protonmail.com), visible in plaintext to anyone intercepting the packet
• Supported cipher suites — The encryption algorithms your browser supports, which can reveal your browser type and version
• TLS version — Which protocol version your client supports
• ALPN extensions — Application-layer protocol negotiation data (HTTP/2, HTTP/3)

The SNI is the most damaging leak. Your ISP can build a complete log of every domain you visit — not the specific pages or content, but the domains themselves. In many jurisdictions, ISPs are legally required to retain this data. Corporate networks routinely use SNI inspection for content filtering. Governments use it for censorship.

A Real-World Example

Imagine you visit a health information site, a political forum, and a job search portal during your lunch break at work. Even though HTTPS encrypts the content of those visits, the SNI field broadcasts those three domain names to your employer’s network in plaintext. TLS encryption protects what you do on each site — but not that you visited them at all.

How Encrypted Client Hello Actually Works

ECH solves the SNI leak by encrypting the entire Client Hello message — including the SNI — before it leaves your browser. Here’s the mechanism step by step:

Step 1: The Server Publishes an ECH Configuration

The website operator publishes an ECH public key in their DNS records (specifically, in an HTTPS-type DNS record). This key is essentially saying: “If you want to connect to me privately, encrypt your Client Hello with this key.”

Step 2: Your Browser Retrieves the ECH Key via DNS

When you type a URL, your browser performs a DNS lookup. If the DNS response includes an HTTPS record with an ECH configuration, your browser extracts the public key. This is where DNS-over-HTTPS (DoH) becomes critical — more on that below.

Step 3: The Browser Sends an Encrypted Client Hello

Your browser constructs the Client Hello as usual, but then encrypts it using the server’s ECH public key. The encrypted version is placed inside an “outer” Client Hello that contains a dummy SNI (typically the CDN’s generic hostname like cloudflare-ech.com). The real SNI is hidden inside the encrypted “inner” Client Hello.

Step 4: The Server Decrypts and Responds

The server (or its CDN edge) decrypts the inner Client Hello using its private key, reads the real SNI, selects the correct TLS certificate, and completes the handshake. From this point forward, the connection is a standard encrypted TLS session.

What an Observer Sees

An ISP or network monitor watching this handshake sees only the outer Client Hello with the generic CDN hostname. They know you connected to Cloudflare (or whichever CDN), but not which specific site behind that CDN you visited. For CDNs hosting millions of domains, this provides meaningful privacy through aggregation.

Browser Support Status for ECH

ECH support has been rolling out gradually across major browsers. Here’s the current status as of 2026:

Browser	ECH Support	Status	How to Enable
Chrome 117+	✅ Supported	Enabled by default	Auto-enabled with DoH active
Firefox 118+	✅ Supported	Enabled by default	Auto-enabled with DoH active
Edge 117+	✅ Supported	Enabled by default	Follows Chrome’s Chromium flags
Safari	⚠️ Partial	iCloud Private Relay integration	Requires Private Relay subscription
Brave	✅ Supported	Enabled by default	Auto-enabled with DoH active
Tor Browser	❌ Not needed	Uses onion routing instead	N/A

The key requirement across all supporting browsers: DNS-over-HTTPS must be active. ECH won’t function if your DNS queries are sent in plaintext, because the ECH configuration keys are delivered via DNS. If an attacker can see or modify your DNS responses, they can strip the ECH keys and force a fallback to plaintext SNI.

How to Enable ECH in Your Browser

Chrome / Edge (Chromium-Based)

1. Open chrome://settings/security (or edge://settings/privacy)
2. Scroll to “Use secure DNS” and toggle it on
3. Select a DoH provider (Cloudflare 1.1.1.1, Google, or a custom provider)
4. ECH activates automatically when DoH is enabled — no additional flags needed in current versions
5. Verify by visiting defo.ie/ech-check.php — it confirms whether your connection used ECH

Firefox

1. Open about:preferences#privacy
2. Scroll to “DNS over HTTPS” and select “Max Protection” (or “Increased Protection”)
3. Choose a DoH provider
4. Firefox enables ECH automatically when DoH is active
5. To verify, navigate to about:networking#dns and look for ECH-related entries, or use the defo.ie checker

Brave

1. Open brave://settings/security
2. Enable “Use secure DNS” and pick a provider
3. ECH support follows Chromium’s implementation — it activates with DoH enabled

If you’re using a privacy-focused setup, consider pairing ECH with a DNS provider that doesn’t log queries. Cloudflare’s 1.1.1.1 has a public audit commitment. NextDNS offers configurable logging policies. Quad9 blocks malicious domains alongside providing DoH.

The Critical Relationship Between ECH and DNS-over-HTTPS

ECH and DoH are not just complementary — they’re interdependent. Here’s why:

Without DoH, your DNS queries travel in plaintext. An ISP or network observer can read them and know which domains you’re resolving. Even if ECH encrypts the SNI in your TLS handshake, the DNS query already leaked the same domain name seconds earlier.

Worse, without DoH an attacker can perform a DNS downgrade attack: they intercept the DNS response, strip the ECH configuration keys, and your browser silently falls back to a plaintext Client Hello with the real SNI exposed.

The Correct Stack

• DoH encrypts your DNS queries — hides which domains you’re resolving and protects the ECH keys in transit
• ECH encrypts the TLS SNI — hides which site you’re connecting to during the handshake
• Together, they close the two biggest metadata leaks in a standard HTTPS connection

Think of it this way: DoH locks the front door, and ECH locks the back door. Leaving either one open defeats the purpose of the other. For anyone serious about anonymous browsing, both need to be enabled simultaneously.

What ECH Still Doesn’t Protect

ECH is a meaningful privacy improvement, but it’s not a silver bullet. Understanding its limitations is just as important as understanding its capabilities.

Your IP Address Is Still Visible

ECH encrypts the SNI, but your IP address remains visible in every packet. The server you connect to, your ISP, and any on-path observer can see your IP. Since IP addresses can be mapped to geographic locations and often to specific households or organizations, this is a significant privacy gap.

Browser Fingerprinting Is Unaffected

ECH operates at the TLS layer. It does nothing to prevent websites from fingerprinting your browser using JavaScript APIs — canvas rendering, WebGL, audio context, installed fonts, screen resolution, timezone, and dozens of other signals. A site with fingerprinting scripts can identify and track you regardless of whether ECH is active. To understand the full scope of this tracking method, read our guide on browser fingerprinting explained.

Cookies and Login State Persist

If you’re logged into a service, ECH doesn’t hide your identity from that service. Cookies, session tokens, and authentication headers still identify you to the website itself. ECH protects you from third-party observers on the network path — not from the destination server.

Traffic Analysis Remains Possible

Even with encrypted SNI, sophisticated observers can use traffic analysis — packet timing, sizes, and patterns — to infer which sites you’re visiting. This is particularly effective against sites with distinctive traffic patterns (e.g., video streaming services).

Server-Side Logging Continues

The website’s server still logs your visit, your IP, and all request data. ECH protects data in transit, not data at rest on the server. This matters for threat models involving legal requests to the hosting provider.

CDN Dependency

ECH currently works best with sites behind CDNs that support it (primarily Cloudflare). Sites that self-host without CDN support won’t offer ECH configurations. The CDN itself also sees all your traffic in plaintext — you’re trusting Cloudflare (or similar) not to misuse that access.

Building a Real Privacy Stack: ECH + DoH + VPN

For meaningful browsing privacy, ECH should be one layer in a multi-layer stack. Here’s how the pieces fit together:

Layer	What It Protects	What It Doesn’t Protect
DoH	DNS queries from ISP snooping	IP address, traffic patterns
ECH	SNI (domain name) in TLS handshake	IP address, fingerprint, cookies
VPN	IP address from destination server	Fingerprint, cookies, VPN provider trust
Browser isolation	Fingerprint, cookies, session data	Nothing at the network layer (needs VPN/proxy)

The Recommended Privacy Stack

1. VPN — Masks your real IP address from destination servers and your ISP. Choose a provider with a verified no-logs policy
2. DoH — Encrypts DNS queries so neither your ISP nor the VPN provider’s DNS can log domain lookups (use a DoH provider separate from your VPN for compartmentalization)
3. ECH — Encrypts the SNI in TLS handshakes, closing the last plaintext metadata leak
4. Isolated browser profiles — Separate fingerprints, cookies, and session data per activity or account

Each layer addresses a different attack surface. Skipping any one leaves a gap that the others can’t cover. This layered approach is fundamentally what safe browsing requires in practice.

When You Need Browser Isolation Beyond ECH

ECH, DoH, and even a VPN all operate at the network level. They protect metadata in transit. But modern tracking has moved far beyond network-level observation. Websites now identify users through browser fingerprinting, cookie graphs, and behavioral analysis — none of which ECH touches.

Scenarios Where ECH Isn’t Enough

• Managing multiple accounts on the same platform — Platforms like Amazon, Facebook, and Google correlate browser fingerprints and cookies across sessions. ECH doesn’t prevent this correlation. You need completely isolated browser environments with distinct fingerprints
• Ad verification across regions — Checking how ads display in different geolocations requires separate browser profiles with different proxies and fingerprints, not just encrypted SNI
• E-commerce multi-storefront operations — Running multiple seller accounts requires that each account appears to come from a different browser, device, and location
• Web scraping at scale — Sites detect and block scrapers using fingerprint consistency checks. ECH doesn’t make your scraping browser look like a different user
• Privacy compartmentalization — Separating your work browsing from personal browsing from financial browsing requires session isolation at the browser level, not just network encryption

What Browser Isolation Provides That ECH Cannot

Browser isolation tools create separate browser environments, each with its own fingerprint, cookies, local storage, and optionally its own proxy or IP address. This means:

• Each profile appears as a completely different user to websites
• Cookies and session data never leak between profiles
• Browser fingerprint parameters (canvas hash, WebGL renderer, fonts, timezone) are unique per profile
• Each profile can route through a different proxy, presenting a different IP and geolocation

ECH protects you from observers between your browser and the server. Browser isolation protects you from the server itself — from its fingerprinting scripts, its cookie tracking, and its behavioral analysis. They solve different problems, and for many privacy-sensitive workflows, you need both.

Frequently Asked Questions

What does Encrypted Client Hello actually encrypt?

ECH encrypts the entire inner Client Hello message, including the Server Name Indication (SNI), supported cipher suites, and other TLS extension data. The most privacy-relevant part is the SNI — the domain name you’re visiting — which was previously sent in plaintext. An outer Client Hello with a generic CDN hostname is sent instead, so observers see only the CDN domain, not your actual destination.

Does ECH work without DNS-over-HTTPS?

Technically ECH can function without DoH, but it’s effectively useless. Without DoH, your DNS queries are plaintext — meaning an observer already sees which domain you’re resolving before the TLS handshake even begins. Additionally, without DoH, an attacker can tamper with the DNS response and strip the ECH configuration keys, forcing your browser to fall back to a plaintext SNI. Always enable DoH alongside ECH.

Is ECH the same as ESNI (Encrypted SNI)?

No. ESNI was an earlier, experimental proposal that encrypted only the SNI field. ECH is its successor and encrypts the entire Client Hello message, providing broader protection. ESNI was deprecated because it had deployment challenges — ECH resolves those with a more robust design that uses an outer/inner Client Hello structure. If your browser or documentation references ESNI, it’s outdated.

Can my ISP still see which websites I visit if ECH is enabled?

With both ECH and DoH enabled, your ISP cannot see the specific domain names you visit through DNS queries or TLS handshakes. However, your ISP can still see the IP addresses you connect to. If a website has a dedicated IP address (not shared via a CDN), your ISP could map that IP back to the domain. They can also use traffic analysis (packet sizes and timing patterns) to make educated guesses. For full IP-level privacy, you need a VPN on top of ECH and DoH.

Does ECH protect against browser fingerprinting?

No. ECH operates at the TLS layer during the initial connection handshake. Browser fingerprinting happens at the application layer — websites use JavaScript to query your browser’s canvas rendering, WebGL capabilities, installed fonts, screen dimensions, timezone, and other parameters. ECH has no interaction with these APIs. To defend against fingerprinting, you need browser-level protections like isolated browser profiles with randomized or spoofed fingerprint parameters.

Which websites support ECH today?

ECH support depends on the server or CDN, not the website itself. As of 2026, Cloudflare enables ECH for all domains on its network — which covers a significant percentage of the web. Other CDNs and hosting providers have been slower to adopt. You can check whether a specific site supports ECH by visiting it with DoH enabled and using a checker tool like defo.ie/ech-check.php, or by inspecting the site’s HTTPS DNS record for ECH configuration data.

Will ECH make VPNs unnecessary?

No. ECH and VPNs solve different problems. ECH hides the domain name in your TLS handshake from network observers. A VPN hides your IP address from the destination server and encrypts all traffic (not just TLS handshakes) from your ISP. ECH doesn’t mask your IP, and a VPN doesn’t encrypt the SNI (unless ECH is also enabled). For comprehensive privacy, use both — they’re complementary, not substitutes.

Can I use ECH with browser isolation tools like Send.win?

Yes. ECH operates at the network/TLS layer, while browser isolation operates at the application layer. They stack cleanly. In Send.win’s Sendwin Browser, each profile can have DoH and ECH enabled in the underlying Chromium engine, while simultaneously running its own isolated fingerprint, cookies, and proxy. This gives you ECH’s SNI encryption plus full session isolation — protecting both your network metadata and your browser-level identity.

How Send.win Helps With Encrypted Client Hello Ech Explained

Send.win is an antidetect browser built for exactly this kind of work — every profile is a clean, isolated identity:

• Isolated profiles – unique fingerprint, separate cookies and storage per profile
• Stealth engine – canvas, WebGL, fonts, and audio spoofed at the engine level
• Desktop app + cloud sessions – native app for Windows, macOS, and Linux, or run profiles in the cloud with no install
• Built-in residential proxies – with automatic timezone, locale, and WebRTC matching
• Team features – share logged-in profiles with teammates without sharing passwords

Try the instant cloud browser demo — no install, no signup — or download the desktop app. The 30-day free trial needs no credit card, and paid plans start at $6.99/month billed annually (see pricing).

Related Products & Resources

• Download
• Pricing
• Proxy Browser Setup Browser Isolation Guide 2026
• Browser Isolation Technology Browser Isolation Guide 2026
• Docker Browser Browser Isolation Guide 2026