Encrypted ClientHello (ECH) Rollout Playbook

Date: 2026-03-27
Category: knowledge
Audience: Platform / security / SRE teams operating TLS termination and DNS

1) Why ECH matters now

TLS 1.3 encrypts most handshake metadata, but classic Server Name Indication (SNI) still exposed the destination hostname to on-path observers.

ECH (Encrypted ClientHello) closes that gap by encrypting the sensitive portion of ClientHello. In 2026, ECH is no longer just a draft-era experiment:

RFC 9849 standardizes TLS ECH.
RFC 9848 standardizes DNS bootstrapping of ECH via SVCB/HTTPS records.

That shifts ECH from “future privacy feature” to an operational migration topic.

2) Correct mental model (what ECH does and does not do)

What ECH protects

ECH protects sensitive handshake fields (especially true target server name) by sending:

an outer ClientHello with innocuous/public info,
an inner ClientHello with real target metadata, encrypted to server-published ECH keys.

What ECH does not magically solve

ECH alone does not hide everything:

destination IP remains visible,
plaintext DNS leaks still leak intent,
traffic-analysis side channels still exist.

So treat ECH as one layer in a privacy stack:

ECH + encrypted DNS transport (DoH/DoT/DoQ) + sane hosting topology.

3) Prerequisites checklist

Before enabling ECH broadly, confirm:

You can publish/manage HTTPS/SVCB records reliably.
DNS change propagation and rollback are fast and monitored.
TLS edge/backend supports ECH-compatible handshake paths.
All targets behind advertised ECH config can actually decrypt/terminate correctly (or are authoritative for the configured public name).
You have observability for ECH accept/reject/fallback and handshake failure classes.

The common production pitfall is not cryptography — it is misconfiguration drift across DNS and TLS fleets.

4) Deployment architecture choices

RFC 9849 frames two practical topologies:

Shared mode: client-facing and backend server are the same entity.
Split mode: client-facing server and backend server are separate.

Operationally:

Shared mode is simpler to reason about.
Split mode can fit CDN/reverse-proxy architectures but demands tighter key/config coordination.

If your edge is distributed, define strict ownership boundaries for:

ECH key lifecycle,
DNS publication,
backend compatibility assertions.

5) Rollout plan (safe sequence)

Phase 0 — Inventory and blast-radius mapping

For each hostname group:

identify termination path,
verify SVCB/HTTPS support,
map dependency on middleboxes / enterprise proxies,
tag “safe candidates” vs “high-risk enterprise-sensitive”.

Phase 1 — Publish but narrow

Publish ECH config via HTTPS/SVCB (ech SvcParam).
Limit initial scope to low-criticality hostnames.
Keep clear rollback path for DNS records.

Phase 2 — Observe acceptance and retry behavior

Track at minimum:

handshake success rate,
ECH acceptance ratio,
ECH rejection + fallback outcomes,
latency deltas around first-connection setup,
error spikes by ASN/region/client family.

Phase 3 — Expand in cohorts

Expand by cohort, not globally:

consumer web traffic first,
enterprise-sensitive networks later,
regulated/inspection-heavy paths last.

Phase 4 — Normalize and rotate

Make ECH key/config rotation part of normal cert/key hygiene (runbook + automation + drills).

6) Enterprise and policy interactions

ECH changes visibility assumptions for networks that depended on plaintext SNI inspection.

Real-world compatibility pattern:

policy/filtering should prefer DNS-layer controls,
some environments intentionally disable ECH by DNS behavior (for policy reasons),
browser behavior may differ under enterprise policy / trusted middlebox settings.

Do not treat this as “broken internet”; treat it as policy boundary negotiation. Publish explicit customer guidance for enterprise admins.

7) Failure modes to plan for

A) DNS/TLS split-brain

Symptoms:

sudden connection retries,
region-specific failures,
intermittent handshake regressions.

Cause:

stale/inconsistent ech parameter vs live server key material.

B) Partial fleet readiness

Symptoms:

only certain POPs or backend pools fail.

Cause:

not all advertised endpoints can satisfy ECH requirements.

C) Middlebox interference

Symptoms:

enterprise-network-specific breakage.

Cause:

assumptions built around SNI visibility.

Runbook principle: rapid DNS rollback + scoped disable switches + ASN-level diagnostics.

8) Minimal observability schema

For each TLS connection (sampled if needed), capture:

client family/version (coarse),
ECH offered? (yes/no),
ECH accepted? (yes/no),
rejection reason bucket,
retry/fallback happened? (yes/no),
end result (success/failure),
handshake latency.

Alert on:

acceptance-rate cliff,
fallback surge,
regional/ASN error concentration,
sustained p95/p99 handshake regression.

9) Practical guidance for teams adopting now

Start with hostnames where you already run modern DNS and TLS automation.
Keep docs explicit about what ECH protects (and what it does not).
Treat DNS publication as part of the security control, not “just plumbing”.
Test from multiple network types (consumer ISP, corporate proxy-heavy, mobile).
Communicate early with enterprise customers about inspection-policy implications.

ECH is best viewed as privacy hardening with operational discipline, not a one-click feature flag.

References

RFC 9849 — TLS Encrypted Client Hello
https://datatracker.ietf.org/doc/rfc9849/
RFC 9848 — Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
https://datatracker.ietf.org/doc/rfc9848/
RFC 9460 — SVCB and HTTPS DNS Resource Records
https://datatracker.ietf.org/doc/rfc9460/
Cloudflare Docs — ECH Protocol
https://developers.cloudflare.com/ssl/edge-certificates/ech/
Mozilla Support — Encrypted Client Hello (ECH) FAQ
https://support.mozilla.org/en-US/kb/faq-encrypted-client-hello