# What Encrypted Client Hello Hides—and What You Still Need to Protect > Canonical HTML: https://www.vpnhive.com/blog/encrypted-client-hello-vpn-limits/ Published: 2026-04-20. ECH can hide part of a TLS connection setup. It does not hide your account identity or every network address, and it is not a reason to assume browsing is anonymous. ## What you will accomplish Use browser protections without buying into an all-or-nothing privacy claim. ## Do it now 1. ### Update the browser Install a supported browser update through its normal update mechanism. On managed devices, follow the organization's process. **Check:** The browser reports that it is current or that an administrator manages updates. 2. ### Review practical controls first Use the browser setup guide to review tracking controls and site permissions. Do not change experimental networking flags just to chase an ECH badge. **Check:** You have checked controls you can maintain and undo. 3. ### Keep the roles separate Use trusted destinations and HTTPS. If you use a VPN, check the app and connection separately; do not infer VPN status from ECH support. **Check:** You can distinguish a browser setting from a VPN connection observation. ## Check the result You can distinguish a browser setting from a VPN connection observation. Change one thing at a time so you know what made the difference. ## If something does not work If a site breaks after a setting change, restore that setting first. ECH support varies between clients, DNS configurations and websites. [Open the Browser Privacy Setup Guide](https://www.vpnhive.com/tools/browser-privacy/) for device-specific steps, completion checks and undo instructions. Background and further explanation **Direct answer:** Encrypted Client Hello (ECH) can hide the specific website name normally exposed through Server Name Indication (SNI) during part of a TLS connection. It does _not_ make a person anonymous, conceal every network clue, hide the destination IP address, or turn a consumer VPN app into an identity shield. This matters to people choosing a VPN for ordinary privacy, network administrators balancing privacy with managed-network controls, and anyone who sees ECH described as a complete answer to tracking. ## ECH protects a field in connection setup, not an entire identity When a browser begins an HTTPS connection, it uses TLS. Before ECH, the TLS ClientHello commonly included an SNI value: the hostname the browser wanted to reach. Encryption protected the later web session, but a network observer could often read that initial hostname. TLS 1.3 substantially improved encryption of handshake material and was designed to provide a secure channel against eavesdropping, tampering, and message forgery, although that does not mean every detail around a connection becomes invisible. See [RFC 8446, the TLS 1.3 specification](https://www.rfc-editor.org/rfc/rfc8446.txt). ECH changes this initial stage. Cloudflare describes it as a TLS extension that splits ClientHello into an encrypted inner portion and an outer portion; in its implementation, the outer portion can use a generic name such as `cloudflare-ech.com`. That design masks the actual SNI from intermediaries for qualifying Cloudflare connections. Cloudflare also says ECH is enabled by default for its Free zones. Those are meaningful product facts, but they do not establish a universal deployment rate or demonstrate that ECH was active for any particular visit. The distinction matters: a documented server-side default does not prove that the browser, DNS path, and network all completed an ECH-capable connection. Think of ECH as a privacy improvement for one formerly conspicuous label on the outside of a connection. It is not a disguise for the device owner, a cure for account-based identification, or a replacement for HTTPS. ## What can still be visible after ECH Hiding the SNI is valuable, but it leaves several categories of information outside its stated purpose: - **Destination IP address:** a network needs an address to route packets. An observer on the path may still see the IP address contacted, even if it cannot read the protected hostname. IP-address inference can be imperfect because shared hosting and content-delivery networks place many services behind an address, but it is not eliminated. - **Connection metadata:** connection times, duration, packet sizes, traffic volume, and the fact that a connection occurred may remain observable to parties in a position to see the traffic. ECH does not promise to obscure those patterns. - **DNS path:** DNS can reveal or influence hostname lookups depending on how it is configured. DNS over HTTPS sends DNS queries and responses over HTTPS, providing confidentiality and integrity for that DNS exchange with the chosen resolver, as defined by [RFC 8484](https://www.rfc-editor.org/rfc/rfc8484.txt). It changes who can observe the query; it does not mean no party can ever associate a query with a user. - **Website and account identity:** signing into an email, shop, social platform, employer service, or school portal identifies an account to that service. Cookies, browser storage, device characteristics, payment records, and voluntarily supplied information are separate issues from SNI. - **Endpoint compromise:** ECH cannot protect a browser or device already compromised by malware, nor can it prevent a website itself from collecting information a user gives it. These limits explain why “the ISP cannot read the hostname in this handshake” is much narrower than “nobody can tell who I am or what I do online.” The latter conclusion does not follow. ## ECH needs compatible clients, DNS, and websites ECH is not a switch that a VPN alone can force on every website. For a successful ECH connection, the client must support ECH, the destination infrastructure must be configured to offer it, and the client needs the relevant ECH configuration information. Modern deployments commonly use DNS HTTPS resource records to publish connection parameters. If those records are absent, changed, unavailable to the client, or intentionally suppressed, the client may not use ECH for that connection. Cloudflare's documentation specifically says enterprise networks that require traffic auditing can disable ECH using DNS-based approaches, including dropping HTTPS resource records, or by using a network canary domain, `use-application-dns.net`. That is a statement about mechanisms Cloudflare documents for managed networks; it should not be read as a recommendation to bypass workplace, school, parental, or legal controls. On a managed device, administrators may also have policies, trusted certificates, proxies, or security software that affect how web traffic is handled. DNS encryption and ECH solve different problems. DoH may protect a DNS lookup on the route to the resolver. ECH may protect the real SNI in a compatible TLS handshake. A browser could have one, both, or neither, and their privacy effects depend on the resolver, browser configuration, destination support, and network policy. Neither protocol removes the need to evaluate the parties that receive data. ## A worked everyday scenario: browsing from a café Suppose Maya connects a laptop to café Wi-Fi and opens a browser to a retailer using Cloudflare. If her browser, its DNS process, the network path, and the retailer's configuration all support ECH, the Wi-Fi operator may not see the retailer's specific hostname in the SNI field that ECH protects. Cloudflare's documentation describes this protection for Cloudflare-hosted connections, using an encrypted inner ClientHello and generic outer name. That does not mean the café network sees nothing. It can still observe that Maya's device connected to an IP address, when the connection started, and broad traffic characteristics. If Maya logs into the retailer, the retailer knows which account logged in. If the device sends ordinary DNS to a local resolver, that DNS activity may expose useful information separately; if it uses DoH, the selected DoH resolver receives the DNS request instead. And if the retailer is not ECH-configured, or Maya's browser does not negotiate ECH, the protection may not apply at all. Now add a consumer VPN app. The café generally sees an encrypted tunnel between Maya's device and the VPN service rather than the final website connection. This can reduce what the café operator learns about individual destinations. But the VPN provider becomes a relevant intermediary: it carries traffic onward and may observe connection metadata needed to operate its service. ECH inside the eventual HTTPS connection can still have value, but it does not make the VPN provider disappear, prove that no logs exist, or hide Maya's retailer account from the retailer. ## Consumer VPN apps and enterprise gateways have different jobs A consumer VPN is usually chosen to encrypt traffic between a personal device and the provider's server, particularly on untrusted local networks, and to present the provider's exit IP address to destination services. For a practical explanation of that tunnel model, see [VPN Service Explained - What is VPN Service & How does it work](https://www.vpnhive.com/vpn-service-work/) and [Understanding the Technology Behind VPN](https://www.vpnhive.com/understanding-technology-behind-vpn/). A VPN can improve privacy against a local network or ISP in specific ways, but it shifts trust toward the VPN company and does not replace TLS encryption to a website. An enterprise gateway is often designed for a different objective: applying security policy, preventing malware delivery, meeting compliance duties, and auditing managed traffic. In that setting, administrators may decide to disable ECH through documented DNS policy because hostname visibility is needed for a chosen security control. Users should understand their organization's acceptable-use rules rather than assume a personal VPN app changes them. Neither category should be judged by an ECH claim alone. A consumer VPN may supply DNS, alter DNS handling, or route traffic through its own infrastructure, but that does not guarantee browser ECH support or destination support. Conversely, an enterprise network may permit ECH and still identify users through device management, authentication, or gateway logs. ## Concrete checks before treating ECH as a privacy benefit 1. **Separate the question:** ask whether the concern is hostname exposure on local Wi-Fi, DNS visibility, account tracking, or a VPN provider's handling of data. One feature rarely answers all four. 2. **Check browser and operating-system documentation:** confirm whether the software in use supports ECH and whether managed policies can disable it. Do not infer activation just because a browser is recent. 3. **Review DNS choices:** identify which resolver receives queries and whether encrypted DNS is enabled. DoH protects the DNS exchange to that resolver, not every subsequent connection fact. 4. **Use HTTPS and sensible account hygiene:** verify the site is HTTPS, use unique passwords and multi-factor authentication where available, and be cautious about information submitted to sites. More guidance is available in [Protect Yourself from Identity Theft & Online Fraud](https://www.vpnhive.com/protect-identity-theft-online-fraud/). 5. **Assess a VPN on its own terms:** review its privacy policy, jurisdictional disclosures, app permissions, pricing, and support rather than buying on a promise of anonymity. The decision framework in [How to Choose The Right VPN](https://www.vpnhive.com/choose-right-vpn/) can help structure that comparison. ## What the available evidence does not establish The supplied Cloudflare documentation establishes how Cloudflare describes ECH on its platform as of its 17 April 2026 update. It does not measure worldwide ECH adoption, name all compatible browsers or resolvers, prove the feature was negotiated on every Cloudflare zone, or establish the privacy practices of VPN companies. RFC 8446 and RFC 8484 define TLS 1.3 and DoH respectively; standards descriptions do not certify that a particular app, network, or website has deployed them correctly. **Takeaway:** ECH can materially reduce exposure of a specific hostname during compatible TLS setup. It is best understood as one layer alongside HTTPS, DNS choices, and—where appropriate—a VPN, not as proof of anonymity or a complete shield against identification. ## Sources 1. [ECH Protocol](https://developers.cloudflare.com/ssl/edge-certificates/ech/) 2. [The Transport Layer Security (TLS) Protocol Version 1.3](https://www.rfc-editor.org/rfc/rfc8446.txt) 3. [DNS Queries over HTTPS (DoH)](https://www.rfc-editor.org/rfc/rfc8484.txt)