Prompt and context
You operate a multi-domain service behind a CDN. Security noticed that TLS still exposes a cleartext SNI in ClientHello and wants to evaluate Encrypted Client Hello (ECH). Explain how clients obtain ECH configuration, what outer and inner ClientHello do, where the CDN-to-origin boundary sits, how old clients fall back, and which metrics diagnose deployment problems.
What the interviewer is testing
The interviewer wants ECH described as a TLS extension, not a VPN, encrypted DNS, or complete traffic anonymity. The client encrypts an inner ClientHello with a server-published public key and sends an outer ClientHello to a client-facing server; the outer name is used for public routing. A strong answer covers HTTPS/SVCB or equivalent configuration delivery, CDN and client support, and the fact that IP addresses, traffic size, timing, and other side channels remain visible.
Clarifying questions to ask first
Observer and privacy target
Clarify whether the threat is a passive observer, an enterprise proxy, or an active man-in-the-middle, and whether a gateway must still enforce domain policy. Each observer sees a different combination of IP, DNS, outer name, and timing.
Topology and key boundary
Confirm whether ECH terminates at the CDN edge or a self-managed entry point and whether the origin still needs independent TLS. Assign ownership for ECH private-key rotation, distribution, and revocation; the CDN public key is not an origin certificate.
Compatibility and fallback policy
Confirm target browsers, operating systems, DoH/DoT, HTTP/3, and enterprise middleboxes. Falling back to cleartext SNI restores compatibility but also restores observer visibility, so policy and metrics must decide when it is acceptable.
30-second answer framework
“ECH encrypts an inner ClientHello with a server-published ECH public key, placing the real SNI and sensitive extensions inside. The outer ClientHello carries a public name so the client-facing server can route the connection. Clients commonly obtain configuration through HTTPS/SVCB records or browser policy, and the edge decrypts the inner message before continuing TLS 1.3. On failure, policy may retry or abort; a cleartext-SNI fallback has weaker privacy. ECH still does not hide IP, DNS, timing, or traffic volume, so it must be evaluated with DNS, CDN, monitoring, and key rotation.”
Step-by-step deep answer
Step 1: Publish ECH configuration
The service publishes an ECHConfig containing a public key, version, and encapsulation metadata. A client obtains it from trusted HTTPS/SVCB records or browser configuration and validates its source. Configuration needs versioning and expiry; stale keys must not remain cached indefinitely.
Step 2: Build outer and inner handshakes
The client puts the real SNI, ALPN, and sensitive extensions in an inner ClientHello encrypted with the ECH public key. The outer ClientHello carries a public name and the encrypted payload. That name points to a client-facing server capable of ECH, rather than revealing the final service domain.
Step 3: Process the message at the edge
The edge receives the outer ClientHello and tries the ECH private key. On success it selects certificates and routing from the inner parameters; on failure it sends a retry configuration or terminates according to TLS rules. TLS from edge to origin remains an independent security boundary; ECH does not replace origin authentication.
Step 4: Handle fallback and attack surface
Expired configuration, incompatible versions, DNS tampering, or a blocking middlebox can prevent ECH. The server may publish a trusted retry configuration and let the client try again. If cleartext-SNI fallback is allowed, scope and log it. Never treat an arbitrary retry configuration as proof of success, because downgrade and misrouting are possible.
Step 5: State what is and is not hidden
ECH primarily hides the site name and related extensions in ClientHello. Observers may still see DNS queries, the outer name, destination IP, handshake timing, connection counts, packet sizes, and later traffic patterns. A unique outer name or a small deployment can shrink the anonymity set.
Step 6: Govern keys and operations
Give ECH private keys rotation, dual approval, rollback, and emergency revocation procedures. Monitor publication time, client acceptance, retry rate, decryption failures, TLS alerts, and version skew across edge nodes. Use diagnostic identifiers that do not contain the inner SNI; logs must not recreate the sensitive data ECH was meant to protect.
Step 7: Roll out and verify gradually
Canary ECH on controlled domains and supported clients. Compare success, fallback, abort, handshake latency, HTTP/2 or HTTP/3 negotiation, and origin errors. Test expired configuration, wrong private keys, middleboxes, and multi-node rotation, then verify that old clients still work under the declared policy.
High-quality sample answer
ECH is a TLS 1.3 extension that encrypts an inner ClientHello with an ECHConfig public key. The real SNI and ALPN remain in the inner message; the outer ClientHello carries a public name and encrypted payload. An ECH-capable CDN edge decrypts the inner message and selects the certificate and route. Edge-to-origin TLS remains separate, and ECH does not replace origin authentication.
I would first define the threat model, DNS/SVCB delivery, CDN key ownership, and fallback policy. Expired configuration, version mismatch, or middlebox interference may trigger a trusted retry; cleartext-SNI fallback is allowed only by explicit policy and is measured. ECH hides handshake fields, not IP, DNS, timing, or traffic volume. During rollout I would monitor acceptance, retry, decryption failure, latency, and origin errors, using versioned configuration and reversible key rotation.
Common mistakes
- Mistake: Assuming ECH makes every visit anonymous. → Why it fails: IP, DNS, timing, and volume can still correlate a connection. → Fix: Describe the anonymity set and remaining side channels, including DNS and CDN deployment.
- Mistake: Treating the ECH private key as the origin certificate key. → Why it fails: Edge decryption and origin authentication are separate boundaries. → Fix: Separate key lifecycles, permissions, and rotation.
- Mistake: Falling back unconditionally after ECH fails. → Why it fails: An attacker can induce failure and downgrade privacy. → Fix: Define retry, abort, and fallback policy with alerts.
- Mistake: Logging the complete inner ClientHello for debugging. → Why it fails: Logs re-expose the site name ECH was meant to hide. → Fix: Log configuration version, node, and error class without sensitive fields.
Follow-up questions and answers
Follow-up 1: How is ECH related to ESNI?
ESNI mainly protected SNI. ECH encrypts a broader inner ClientHello and defines outer/inner coordination and configuration delivery. Use the current ECH standard and deployment documentation; old ESNI terminology is not a complete implementation plan.
Follow-up 2: How can an enterprise audit traffic when the middlebox cannot see the real domain?
First determine whether the organization controls endpoints and egress gateways. Managed devices can provide policy signals to a trusted agent or proxy. On public networks, hiding SNI is not a TLS failure; privacy and organizational visibility must be reconciled through explicit policy.
Follow-up 3: Why does the outer name affect privacy?
If one outer name serves only one real site, IP, DNS, and that name can still narrow the destination. Shared entry points and a larger anonymity set improve privacy but add routing, certificate, and operational complexity.
Follow-up 4: How do you distinguish ECH failure from ordinary TLS failure?
Correlate whether the client sent ECH, configuration version, edge retry, decryption-failure counters, TLS alerts, node, and time window. Reproduce with ECH enabled, disabled, and an old configuration on the same client so certificate, ALPN, or origin-health issues are not mislabeled as ECH failures.