TLS 1.3, Encrypted Client Hello (ECH) & HPKE Architecture Studio

When TLS was originally designed, virtual hosting required the client to announce which hostname it wished to connect to before the server could select the correct X.509 certificate and cryptographic cipher suite. Because the TLS handshake begins with the ClientHello before any encryption keys have been negotiated, the SNI extension was transmitted in cleartext. Even in standard TLS 1.3—where the certificate and all subsequent handshakes are encrypted—the initial ClientHello and SNI remain in plaintext, allowing Internet Service Providers, network routers, and state-level DPI firewalls to log and censor every visited website.

ECH splits the ClientHello into two separate messages: an Outer ClientHello and an Inner ClientHello. The Outer ClientHello contains a benign, public-facing cover domain (e.g. cloudflare-ech.com or public-cdn.net) visible to eavesdroppers. The Inner ClientHello contains the actual sensitive destination hostname, ALPN protocols, and extensions. The client encrypts the Inner ClientHello using Hybrid Public Key Encryption (HPKE RFC 9180) with a public key retrieved out-of-band via DNS (HTTPS RR Type 65) and includes the encrypted ciphertext inside the ECH extension of the Outer ClientHello.

Before a browser can encrypt the ClientHello, it must know the server public key, supported KEM algorithms, and symmetric cipher suites. RFC 9460 specifies that authoritative DNS servers publish this cryptographic metadata in an HTTPS record (Type 65) via the "ech" parameter containing a Base64-encoded ECHConfigList. When paired with encrypted DNS protocols (DNS over HTTPS or DNS over TLS), the client retrieves the server ECH public key privately, preventing network observers from learning the destination via DNS.

TLS 1.3 uses a multi-stage HKDF (HMAC-based Extract-and-Expand Key Derivation Function) state machine. It begins with an Early Secret (derived from an optional Pre-Shared Key). Next, it extracts the ephemeral Diffie-Hellman secret (from X25519 key exchange) into the Handshake Secret, generating client_handshake_traffic_secret and server_handshake_traffic_secret to encrypt the remaining handshake messages (certificates and verify signatures). Finally, it extracts a derived master secret to produce client_application_traffic_secret_0 and server_application_traffic_secret_0 for bidirectional application payload encryption.