encrypted_client_hello
Encrypted Client Hello (ECH, RFC 9849) encrypts the SNI and other ClientHello fields. Chrome always sends it, real or GREASE.
What it is
encrypted_client_hello (extension 65037, 0xFE0D) carries Encrypted Client Hello, standardized in RFC 9849 in March 2026. ECH splits the ClientHello in two: an outer one with harmless values that anyone can read, and an inner one, encrypted to the server's public key, that holds the real server name and other sensitive fields.
The server publishes its ECH key in DNS, in an HTTPS record. A client that finds the key encrypts the inner ClientHello with it; observers on the network then see only the outer name, usually that of the CDN.
When a client has no ECH key for a site, browsers still send the extension with random content, a practice called ECH GREASE. This keeps real ECH traffic from standing out and makes sure middleboxes tolerate the extension.
Who sends it
Measured on 2026-10-25 against our own test server: sent by 2 of 12 clients. Position counts from 1 and ignores GREASE values.
Why it matters for fingerprinting
In our measurements only Chrome 153 and curl_cffi impersonating Chrome send it. None of the plain libraries do: curl, Python requests, httpx, Go net/http, Node.js fetch and Guzzle. Older impersonation profiles such as curl-impersonate chrome116 lack it too.
Because Chrome sends ECH, real or GREASE, on every connection, a ClientHello that claims to be Chrome without this extension is a clear mismatch.
Check whether your client sends it
Open the test from your browser, or call it from your script, and look for encrypted_client_hello in the TLS details.
Run the TLS fingerprint test