Writing

Encrypted Client Hello test: is ECH working?

Published 24 September 2026

A useful Encrypted Client Hello test has three parts: prove the domain publishes an ECH configuration in its DNS HTTPS record, prove the client can use ECH, then require ECH for the connection. A normal HTTPS success or an ech= value by itself is not proof that the real ClientHello was encrypted.

The shortest conclusive test

First inspect the HTTPS resource record. It carries the ECH configuration clients need before the TLS connection begins. Replace example.com with the hostname being tested: 

dig +short HTTPS example.com

Look for an ech= service parameter. Its presence proves the DNS answer advertises ECH; it does not prove the client retrieved that answer, understood it, or completed ECH with the server.

For a command-line test, use a curl build with ECH support and encrypted DNS. --ech hard refuses to continue when ECH cannot be used, which removes the silent-fallback ambiguity: 

curl -V

curl --ech hard \
  --doh-url https://1.1.1.1/dns-query \
  --verbose \
  --output /dev/null \
  https://example.com/

A successful request in hard mode is the useful result. If curl reports that --ech is unsupported, test the client build rather than the site: ECH depends on curl's TLS backend and HTTPS-record support, and remains an experimental curl feature as of September 2026.

What Encrypted ClientHello actually hides

TLS 1.3 encrypts the server certificate and almost everything after the opening handshake, but the traditional ClientHello exposes Server Name Indication: the hostname the client wants. That allows one IP address to serve many certificates, but also lets an on-path observer learn the destination before application data is encrypted.

ECH builds an inner ClientHello containing the real SNI and other sensitive extensions, encrypts it to the client-facing server, and wraps it in an outer ClientHello with a public name. RFC 9849 standardized the mechanism in March 2026. RFC 9848 defines how clients discover the configuration through DNS SVCB and HTTPS records.

This is separate from the key exchange. The X25519MLKEM768 hybrid protects the session secret against a future quantum computer; ECH protects the real ClientHello fields from an observer now. A connection may use either, both, or neither.

Why DNS is part of an ECH test

The client cannot encrypt the inner hello until it has the server's ECH public configuration. That configuration usually arrives in an HTTPS DNS record. If the local resolver strips the record, returns an old value, or the client never asks for HTTPS records, the TLS endpoint can be perfectly configured while the client sends no real ECH offer.

Plaintext DNS also weakens the privacy result. ECH can hide the SNI on the TLS connection while a local observer reads the same hostname in an unencrypted DNS query moments earlier. That is why the curl test uses DNS over HTTPS. To compare ordinary A, AAAA and HTTPS answers across resolvers, the Kodura DNS lookup makes the DNS half of the path visible.

Do not publish an ECH configuration through one DNS path and test through another without saying so. A corporate resolver, split-horizon zone or security appliance may return a different HTTPS record from the public resolver in a browser.

Read each result at the right layer

ResultWhat it provesWhat it does not prove
ech= appears in DNSThe resolver returned an ECH configuration for that name.The client used it or the server accepted it.
Ordinary browser or curl request succeedsHTTPS works through some negotiated path.ECH was attempted; clients may fall back.
curl --ech hard succeedsThis ECH-capable client obtained a configuration and required ECH for the request.Every browser, resolver and network path will do the same.
Packet capture shows an outer nameThe real SNI is not visible in that captured ClientHello.The destination is impossible to infer from IP, DNS or traffic patterns.

When the ECH test fails

  1. No HTTPS record: the zone or CDN has not advertised an ECH configuration through the resolver you queried.
  2. HTTPS record but no ech=: the record may advertise HTTP/3 or an alternative endpoint without enabling ECH.
  3. curl rejects --ech: the binary or TLS backend lacks ECH support. curl -V identifies the build.
  4. Hard mode fails after DNS succeeds: compare the exact resolver result, test from another network, and check for stale ECH keys or a middlebox that mishandles the extension.
  5. Browser works but hard mode fails: the browser may use a different resolver, cached configuration, CDN path or fallback policy. The two requests are not yet equivalent.

If the failure is a reset, timeout or TLS alert rather than an explicit ECH diagnostic, locate who sent it before changing the certificate. The workflow in SSL handshake failed separates endpoint rejection from a device in the path. The Kodura SSL checker can verify the public endpoint's ordinary TLS versions and chain, but it is not an ECH test.

ECH is privacy, not invisibility

ECH protects the inner SNI and other ClientHello fields. It does not hide the destination IP address, erase DNS leakage outside an encrypted resolver path, or make traffic size and timing indistinguishable. Its anonymity set is the group of ECH-enabled names sharing the same client-facing server and externally visible behaviour.

It also changes what TLS interception products can see. A firewall that relied on plaintext SNI may block ECH, force a different path, or require an explicit policy decision. Treat that as an architecture choice, not as evidence the protocol is broken. Test from the employee, guest, VPN and direct-internet paths separately; they often have different DNS and TLS handling.

Sources

Protocol status and client commands were checked on 24 September 2026.