How to Test Encrypted Client Hello Through a Proxy

Encrypted Client Hello, or ECH, protects sensitive fields in the TLS ClientHello, including the destination name carried in SNI. That changes what a passive network observer can see, but it does not make every proxy path private, compatible or correctly configured.

A browser may discover an ECH configuration in a DNS HTTPS record, send only a GREASE placeholder, retry after a configuration mismatch, fall back without ECH or reuse an existing connection. A page loading successfully therefore does not prove that ECH was accepted.

This guide builds a controlled acceptance test for authorized infrastructure. It covers explicit HTTP CONNECT proxies, HTTPS proxies, managed TLS inspection and direct control paths. It does not attempt to bypass organizational policy or conceal traffic from a proxy operator.

Start with the visibility boundary

Write down what each component can observe before collecting packets:

ECH does not hide the CONNECT hostname from an explicit proxy when the client sends that hostname in the CONNECT request. Test privacy and compatibility claims separately.

Use the proxy TLS interception audit to identify every termination point before evaluating ECH.

Define a small controlled matrix

Use a destination and DNS zone you control, or a provider-supported test endpoint. Prepare:

1. ECH-enabled HTTPS record with a current configuration;
2. the same destination without an ECH configuration;
3. a deliberately stale test configuration in an isolated zone;
4. a resolver path that returns A and AAAA but not HTTPS records;
5. direct, HTTP CONNECT and HTTPS proxy routes;
6. managed inspection only where it is explicitly authorized.

Keep application content, account state, client build and region constant. Change one variable at a time. Do not manipulate third-party DNS or production inspection controls.

Verify DNS ownership first

ECH depends on the client receiving a usable configuration, commonly through DNS HTTPS service bindings. Capture the resolver class, response code, HTTPS record presence, configuration identifier or hash, TTL and answer age.

Compare the client-visible answer on each route. A proxy may not carry DNS at all; the operating system, browser secure DNS setting or SOCKS remote-DNS mode may choose a different resolver. The SVCB and HTTPS DNS compatibility test provides a broader baseline for record discovery and alias handling.

Do not log the complete browsing history or customer hostnames. Use owned fixtures, pseudonymous route labels and hashes for configuration comparison.

Prove acceptance, not just an extension

Seeing an encrypted_client_hello extension does not prove successful ECH. Clients can send GREASE values even when no usable configuration is available. Your evidence should distinguish:

• no ECH attempt;
• GREASE-only offer;
• real ECH offer using the expected configuration;
• server acceptance;
• authenticated retry configuration;
• clean failure;
• fallback or retry without ECH.

Prefer client or server diagnostics that explicitly report acceptance. If packet capture is permitted, treat it as supporting evidence and minimize retention. Never infer acceptance only from a successful HTTP response.

Isolate the proxy hop

Run the same cold test in this order:

1. approved direct control path;
2. HTTP CONNECT proxy;
3. HTTPS proxy with its client-facing TLS hop verified separately;
4. managed inspection path, if applicable.

Close eligible connection pools between cold cohorts. Record proxy negotiation, CONNECT result, destination TLS result, ECH state, ALPN, address family and total time.

For an HTTPS proxy, the TLS connection to the proxy and the TLS connection through CONNECT are different. ECH for the destination does not validate the proxy certificate. Use the ALPN negotiation audit to keep protocol negotiation failures separate from ECH failures.

Detect retry and fallback

Configuration rotation can cause a server to reject an old ECH configuration and provide retry information. A conforming client may open a new transport connection and try again. That is different from silently disabling ECH and continuing on the same evidence path.

Capture a bounded event sequence:

route_alias
client_build
resolver_class
https_record_hash
ech_offer_class
ech_acceptance
retry_count
fallback_class
connect_ms
tls_ms
total_ms
result_category

Use a unique non-sensitive request marker to correlate client, proxy and destination observations. Never record proxy passwords, cookies, private keys or raw customer destinations.

An ECH test fails when the client unexpectedly opens a direct connection after the proxy route fails. Apply the proxy bypass audit to every retry, not only the first attempt.

Test warm and cold behavior

DNS TTLs, ECH configuration caching, TLS session resumption and connection reuse can hide changes. Run:

• a cold process with empty DNS and connection state;
• a second request inside the DNS TTL;
• a request after the controlled configuration rotates;
• a request after cache expiry;
• a warm request eligible for session resumption;
• a fresh connection after a route change.

Do not claim a rotation problem when the request reused an existing connection and performed no new DNS or TLS handshake. Record whether each test actually created a new transport.

Set acceptance gates

A route passes only when:

• the expected DNS HTTPS record reaches the intended client;
• real ECH and GREASE-only offers are distinguishable;
• destination-side evidence confirms acceptance when expected;
• stale configuration follows the documented retry behavior;
• no unapproved direct fallback occurs;
• proxy and destination TLS failures remain separately attributable;
• explicit-proxy visibility is described accurately;
• managed inspection behavior matches organizational policy;
• connection reuse and caching cannot masquerade as a fresh success;
• logs contain aliases and hashes rather than secrets or browsing histories.

Troubleshooting map

The GeoDNS consistency test helps separate regional answer drift from ECH configuration problems.

FAQ

Does ECH make an explicit proxy unable to see the destination?

Not necessarily. An explicit proxy can receive the destination hostname in the CONNECT authority even when the later TLS ClientHello protects SNI. Document the actual application-to-proxy protocol.

Is an ECH extension in a packet enough to prove ECH works?

No. It may be GREASE. Confirm a real configuration was used and obtain client- or server-side acceptance evidence.

Should we disable certificate verification to isolate an ECH error?

No. Certificate, hostname and ECH checks protect different properties. Keep verification enabled and use controlled certificates.

Can a proxy exit change fix a stale ECH configuration?

Only if the route changes the resolver or destination edge evidence, and that difference must be explained. Random rotation is not a valid fix. Diagnose DNS, configuration age and retry behavior directly.

Compliance note

Test only destinations, DNS zones, clients and proxy infrastructure you own or are authorized to assess. Respect network policy, privacy obligations and provider terms. Do not use ECH testing to bypass access controls, hide prohibited activity or weaken approved inspection without authorization.