Prompt and scope
TLS 1.3 encrypts most handshake content, but a traditional ClientHello can expose SNI and let an observer infer the target service. Explain ECH’s protocol role, key-configuration delivery, and failure behavior, and distinguish hiding SNI from hiding all traffic characteristics.
This fits networking, security, platform, and general protocol roles. Its core skill is TLS handshake and privacy boundaries, so it belongs to general.
What interviewers assess
First, do you understand the outer and inner ClientHello? ClientHelloOuter provides a compatibility shape while the real target is placed in ClientHelloInner encrypted with the server’s configured public key.
Second, can you explain configuration delivery? ECHConfig contains a public key and algorithm metadata; it can be discovered through DNS SVCB/HTTPS records, but authenticity and freshness still matter.
Third, do you know that ECH is not end-to-end anonymity? DNS, IP, timing, certificates, and paths without ECH can still reveal information.
Fourth, can you explain failure fallback? A client may retry or send a normal ClientHello when ECH is unavailable. The policy must not count a failed privacy attempt as success.
Fifth, can you design verification? Inspect handshake extensions, edge metrics, configuration hit rate, and fallback rate instead of checking only HTTPS success.
Questions to clarify first
- Do the client, edge proxy, and TLS library support RFC 9849?
- How is ECHConfig delivered, and how are DNSSEC or encrypted DNS handled?
- Does the service have a shared frontend and multiple backend names?
- Is plaintext-SNI fallback allowed, or must privacy failure be a hard failure?
- Are we protecting a domain, tenant name, or broader traffic metadata?
- Can telemetry record ECH success without logging the inner name?
30-second answer framework
“ECH places the real target in ClientHelloInner and encrypts it with HPKE using the public key published in ECHConfig; ClientHelloOuter keeps the handshake compatible. ECHConfig can be delivered through DNS SVCB/HTTPS, with authenticity and freshness checks. On failure, the policy chooses fallback or hard failure, and TLS success is not privacy success. Verification combines handshake extensions, edge metrics, configuration hits, and fallback rates while acknowledging that DNS, IP, and traffic patterns remain visible.”
Step-by-step answer
Step 1: Separate the two ClientHello messages
The client builds ClientHelloInner with the real SNI and extensions it wants to hide, then creates ClientHelloOuter as a compatibility message. The server or edge uses the ECHConfig key to decrypt the inner message; if it cannot, it handles failure according to the protocol.
Step 2: Understand HPKE and configuration
ECHConfig carries a version, public key, cipher suites, and server metadata. The client uses HPKE to protect ClientHelloInner, while the server holds the matching private key. Rotation needs overlapping validity, cache control, and revocation; do not hard-code the key in clients.
config = fetch_ech_config()
inner = build_client_hello(real_sni, extensions)
outer = build_outer_hello(public_name, ech_extension)
encrypted_inner = hpke_seal(config.public_key, inner)
send(outer, encrypted_inner)Step 3: Discuss DNS delivery and authenticity
ECHConfig can be discovered through SVCB/HTTPS records. Evaluate freshness, caching, and tampering risk; encrypted DNS protects only part of the path, while DNSSEC and application policy determine trust. Refresh on invalid or expired configuration.
Step 4: Define failure and fallback
Decryption failure, expired configuration, GREASE, or extension incompatibility can trigger retry or an ordinary handshake. Decide which domains allow fallback and which privacy requirements require a hard failure, and record the reason. Fallback is not ECH success.
Step 5: Identify remaining exposure
ECH hides the target name in ClientHello, but DNS queries, destination IP, timing, packet sizes, certificates, and application behavior can still support traffic analysis. State the goal as reducing specific handshake metadata exposure, not anonymity.
Step 6: Plan deployment and key rotation
Deploy edge private keys with least privilege and audit trails, and publish overlapping old and new configurations. Multi-region caches need consistent versions and invalidation. On key compromise, revoke the old configuration, shorten TTL, and watch fallback rates.
Step 7: Build end-to-end acceptance
Test clients with and without ECH, multiple DNS paths, and multiple edge nodes. Record extension negotiation, configuration version, decryption failures, fallback rate, handshake latency, and connection errors. Packet validation must not log the sensitive inner name.
Model answer
“ECH is a TLS handshake extension, not an application-layer tunnel. The client places the real SNI in ClientHelloInner, encrypts it with HPKE using the ECHConfig public key, and sends a compatible ClientHelloOuter. ECHConfig can be discovered through SVCB/HTTPS, so deployment must address DNS authenticity, caching, and rotation.
I would define failure policy explicitly: hard-fail privacy-sensitive endpoints and observe ordinary fallback on compatibility endpoints. Telemetry covers negotiation, configuration hits, decryption failures, fallback, and handshake latency without logging the inner name. DNS, IP, certificates, and traffic patterns still require separate privacy analysis. Acceptance spans clients, DNS paths, and key rotation.”
Common mistakes
- Claiming ECH hides all traffic → DNS, IP, and timing remain visible → state a bounded privacy goal.
- Hard-coding ECHConfig keys → rotation and revocation become difficult → use refreshable configuration.
- Checking only HTTPS success → ordinary fallback is counted as ECH → record extensions and fallback reason.
- Ignoring DNS tampering and stale caches → clients use bad configuration → evaluate authenticity, TTL, and refresh.
- Treating outer SNI as the real target → compatibility name is misunderstood → separate public name and inner SNI.
- Rotating keys without overlap → multi-region clients fail intermittently → use an overlap and invalidation plan.
- Logging the inner name → telemetry re-leaks privacy → log only hashes, versions, and states.
- Ignoring unsupported clients → real users cannot connect → keep explicit fallback or hard-fail rules.
Follow-up questions
Follow-up 1: How do ECH and DoH/DoT relate?
ECH protects the TLS ClientHello; DoH/DoT protect DNS transport. They address different stages and can be combined, but neither replaces the other.
Follow-up 2: Why is ClientHelloOuter needed?
It provides a compatibility shape so middleboxes that do not understand ECH can still process the handshake while the real target stays in the encrypted inner message.
Follow-up 3: Must ECH always fall back on failure?
No. The policy depends on privacy and availability requirements. A privacy-sensitive endpoint may hard-fail; a compatibility endpoint may fall back but must make that observable and countable.
Follow-up 4: How do you verify middleboxes did not break ECH?
Record negotiation separately at client, edge, and server, then compare success, fallback, and handshake errors across proxy paths.
Follow-up 5: What happens after key compromise?
Revoke or stop publishing the old ECHConfig, shorten cache TTL, deploy a new key, and monitor decryption failures and fallback. Previously exposed ClientHellos cannot be made private retroactively.
Follow-up 6: Does ECH hide domain names in certificates?
It primarily hides the target name in the handshake. Certificates, DNS, IP, and application information may still correlate the domain, so complete domain concealment cannot be promised.