Why the TLS ClientHello can reveal a website name
HTTPS encrypts page content, form data, cookies, and most request details. Before that encrypted session is established, the browser sends a TLS ClientHello containing connection options. Traditional deployments include the Server Name Indication value so a shared server knows which certificate and website to present. A network observer can often read that hostname even though the later page content is encrypted.
How Encrypted Client Hello works
ECH encrypts the sensitive inner ClientHello using a public configuration published by the website, commonly discovered through modern DNS HTTPS records. The browser sends an outer ClientHello that allows the connection to reach a compatible fronting service, while the real server name and other protected parameters remain inside the encrypted message.
The server or edge provider uses the matching private key to open the inner message and continue the normal TLS handshake. If ECH is unavailable or fails, browser behavior depends on policy and configuration. Secure deployment must avoid silently exposing information through an unsafe downgrade.
What ECH hides—and what remains visible
- Helps hide: the real TLS server name and selected ClientHello metadata from passive network observers.
- Does not hide: the destination IP address, traffic timing, packet sizes, the fact that a connection occurred, or information revealed by an unencrypted DNS lookup.
- Does not replace: HTTPS, encrypted DNS, a VPN, access control, or application privacy protections.
If many websites share a large content-delivery network address, hiding the server name can provide meaningful ambiguity. If one IP hosts only one recognizable service, the destination address may still reveal the likely site.
Why encrypted DNS often matters with ECH
A browser may need an HTTPS DNS record to obtain the ECH configuration. If the DNS query itself is visible in plain text, an observer can learn the hostname before the protected TLS connection begins. DNS over HTTPS or DNS over TLS can reduce that exposure between the device and its chosen resolver, although the resolver still processes the query.
Why ECH is not active everywhere
ECH requires support from browsers, operating systems or applications, DNS resolvers, authoritative DNS, and the website's TLS infrastructure. Enterprise inspection products and captive portals can also complicate deployment. Large content-delivery networks can roll it out more easily because they already terminate TLS for many domains.
Users normally do not need to configure ECH manually. A compatible browser and resolver negotiate it when the destination publishes valid configuration. Browser diagnostic pages may show whether the connection used ECH.
Does ECH make a VPN unnecessary?
No. ECH protects a specific part of the TLS handshake. A VPN changes what the local network sees by carrying traffic through an encrypted tunnel to a VPN gateway. The two technologies solve different problems and can be used together.
Frequently asked questions
Is ECH the same as ESNI?
ECH is the standardized successor to the earlier Encrypted SNI experiment and protects more of the ClientHello.
Can my Internet provider still see the destination IP?
Yes, unless another layer such as a VPN or proxy changes the visible destination.
Can a website tell that I used ECH?
The terminating service participates in the ECH handshake, so it knows. The goal is to reduce exposure to intermediaries.
How can I enable ECH?
Keep the browser updated and use a compatible encrypted DNS configuration. Availability still depends on the website.
Standards reference: ECH is defined through the IETF TLS working process and is deployed alongside HTTPS DNS resource records.