Question and scope
An enterprise wants to reduce the target site name visible to network intermediaries, but worries about legacy clients, TLS-inspecting proxies, and stale configuration. Design an ECH rollout, monitoring, and fallback plan covering ClientHelloInner, ClientHelloOuter, ECHConfig, DNS publication, shared or split topology, key rotation, and downgrade safety.
RFC 9849 defines ECH as encrypting ClientHello under a server public key; RFC 9848 defines configuration publication through SVCB and HTTPS records. ECH protects selected handshake metadata. It does not hide IP addresses, traffic patterns, or the endpoints themselves.
What the interviewer is testing
- Explain the public outer envelope, the real inner handshake, and who decrypts and forwards it.
- Describe ECHConfig sources, configuration identifiers, key rotation, and DNS-cache consistency.
- Compare shared and split modes with explicit trust and certificate boundaries.
- Avoid claiming that ECH makes all traffic anonymous; discuss IP, DNS, traffic analysis, and endpoints.
- Handle legacy clients, middleboxes, inspection,
retry_configs, and unsafe downgrade paths. - Validate a rollout with acceptance, retry, handshake-error, and policy-hit metrics.
Questions to clarify first
- Is the goal to hide SNI from public observers, or also to satisfy enterprise inspection, regional policy, or compliance retention?
- Who controls the client DNS resolver and browser policy? What are the legacy-client, mobile-network, and enterprise-proxy shares?
- Does one service terminate TLS, or does an edge provider decrypt and forward to a backend?
- What DNS TTL and key-overlap window are acceptable, and may ECH be disabled temporarily during an incident?
- Which metrics must exclude real domains or user identity, and how long are logs retained?
A 30-second answer
I would define the threat model first: ECH hides the real site name in ClientHello, not IP addresses or traffic patterns. The server publishes ECHConfig; the client builds an encrypted inner and a public outer; the edge decrypts and hands the inner to the backend. I would canary it, measure acceptance, retries, and handshake errors, and rotate keys with an overlap window. Legacy clients may use ordinary TLS, but an ECH failure must not blindly expose the real SNI. Enterprise policy should move to controlled DNS or an explicit proxy boundary, with a tested safe fallback.
Step-by-step deep dive
1. Define the protection boundary
ECH lets an observer see a public name or edge service rather than the real SNI. IP address, timing, packet sizes, DNS queries when DNS is not encrypted, and endpoint certificate policy can still leak information. State the goal as reducing handshake metadata, not anonymizing a connection.
2. Explain the inner and outer flow
The client selects a key and parameters from ECHConfig, puts the real ClientHello in ClientHelloInner, and constructs ClientHelloOuter with an encrypted_client_hello extension. The outer uses a public name. The edge authenticates and decrypts it, then passes the inner to the backend. The server authenticates the outer associated data so an attacker cannot modify outer fields.
DNS HTTPS/SVCB -> ECHConfig(public name, key, config_id)
client -> encrypt(ClientHelloInner) -> ClientHelloOuter
edge -> decrypt and validate -> backend handles ClientHelloInner3. Choose shared or split topology
In shared mode one service faces the client and terminates backend TLS. In split mode the edge decrypts ECH and forwards the inner to an independent backend. Split mode needs explicit edge-to-backend trust, certificates, connection protection, and failure ownership; the edge is not automatically a harmless plaintext observer.
4. Publish configuration and rotate keys
Publish ECHConfig in HTTPS/SVCB records with a controlled TTL, and serve old and new configurations during rotation. Each configuration carries a public key, version, and identifier. Monitor DNS caching, configuration selection, and decryption failures. Retire the old private key only after cache, connection, and retry windows have elapsed.
5. Handle failure and legacy clients
Clients without ECH can use ordinary TLS; ECH-capable clients can refresh settings after receiving retry_configs. RFC 9849 forbids a client from simply sending an unencrypted real ClientHello after ECH rejection, because an active attacker could induce SNI disclosure. Servers should provision every possible endpoint with a certificate valid for the public name.
6. Handle middleboxes and enterprise policy
A TLS-terminating proxy that does not understand ECH may connect using the public outer name, so SNI-based inspection can stop matching. Move policy to a controlled DNS resolver, explicit proxy, or managed browser boundary, and version the policy. Do not assume that modifying DNS is harmless; rehearse DNSSEC, regional networks, and emergency disablement.
7. Canary and observe
Enable one site, region, and controlled client cohort first. Compare ECH acceptance, ech_required, retry rate, TLS failures, DNS-cache hits, and end-to-end latency. Log configuration identifiers, edge locations, and error classes without defaulting to real inner SNI. If handshakes, policy enforcement, or compatibility regress, disable narrowly by site or client rather than globally downgrading.
High-quality sample answer
I would position ECH as SNI privacy enhancement, not as IP or traffic-pattern anonymity. After DNS publishes ECHConfig, the client encrypts the real ClientHelloInner and sends a ClientHelloOuter with a public name. The edge validates and decrypts it, then hands the inner to a TLS backend under a clearly documented shared or split trust model.
I would canary first, rotate keys with overlapping configurations and TTL windows, and monitor configuration selection, acceptance, retry_configs, ech_required, handshake errors, and latency. Legacy clients may use ordinary TLS, but an ECH-capable client must not expose the real SNI after an induced failure. SNI-dependent enterprise controls move to DNS or an explicit proxy. Logs keep only redacted identifiers and error classes, and rollback and DNSSEC scenarios are rehearsed.
Common mistakes
- Claiming ECH hides IP and all traffic features → the threat model is overstated → state that it protects selected ClientHello metadata.
- Publishing a key without DNS-cache and rotation design → clients keep stale settings → define TTL, overlap, and retirement conditions.
- Sending the real SNI in cleartext after ECH failure → an active attacker can induce disclosure → follow rejection, retry, and safe termination rules.
- Treating edge decryption as trust-free plaintext handling → split-mode boundaries are missing → name edge, backend, certificate, and link-protection duties.
- Measuring only successful handshakes → legacy and enterprise regressions disappear → segment by client, network, region, and error class.
Follow-up questions and answers
Does ECH prevent DNS leakage?
No. ECHConfig is commonly obtained through HTTPS/SVCB records; an unencrypted DNS path can still reveal the query. Evaluate ECH, encrypted DNS, certificates, and network policy separately.
What can the edge see in split mode?
It must decrypt ECH and forward the inner, so it sees information required for handshake processing. Application visibility depends on where subsequent TLS terminates. Document minimum trust, link protection, and log boundaries.
Why not retry a normal ClientHello after failure?
An active attacker could cause ECH failure and induce real-SNI disclosure. A safe implementation uses retry_configs, public-name authentication, or connection termination within the client fallback rules.
How do you rotate ECH keys?
Publish the new configuration while retaining the old one through DNS TTL, connection lifetime, and retry windows. Observe hits and decryption failures by configuration identifier, then retire the old private key after the overlap period.
What if an enterprise must inspect SNI?
Clarify policy and legal boundaries, then use a controlled DNS resolver, explicit proxy, or endpoint-management policy selectively. Do not assume DNS rewriting has no DNSSEC, compatibility, or availability cost.
Acceptance drops while TLS success stays flat. What do you inspect?
Compare DNS resolvers, client versions, edge locations, and configuration identifiers. Check HTTPS-record caching, key versions, public-name certificates, and retry_configs; distinguish a configuration transition from a handshake fault.