Encrypted Client Hello (ECH) is a security feature in the TLS (Transport Layer Security) protocol aimed at improving privacy by encrypting the Client Hello message in the TLS handshake. The Client Hello message contains various information, including the hostname (Server Name Indication or SNI) that the client wants to connect to. By encrypting this information, ECH helps prevent eavesdroppers from knowing which website the user is trying to visit, enhancing privacy.

Simple Explanation

Imagine you want to send a letter to your friend, but you don’t want anyone to know who you’re sending it to. ECH is like putting your friend’s address inside the envelope instead of writing it on the outside, so only the postal worker at the final delivery stage can see where it needs to go.

How ECH Works

  1. Initial Connection: When a client (like your web browser) wants to connect to a server, it sends an initial connection request. This request includes some public information that allows the server to understand that the client supports ECH.

  2. Key Distribution: The server provides a public key, which the client uses to encrypt the Client Hello message. This key is usually distributed via DNS or another out-of-band method.

  3. Encrypted Client Hello: The client encrypts the Client Hello message using the server’s public key and sends it to the server. This encrypted message includes the SNI and other necessary details.

  4. Decryption by Server: The server, upon receiving the encrypted Client Hello, decrypts it using its private key. This allows the server to see the SNI and other details, and proceed with the TLS handshake as usual.

Network Routing with ECH

You might wonder how network devices like routers and load balancers can route traffic correctly if the SNI is encrypted. Here’s how it works:

  1. Initial Unencrypted Part: The very first part of the handshake (before the encrypted Client Hello) contains enough information for the network to route the packet to the correct server or service provider. This includes the IP address of the server and possibly some metadata indicating that ECH is being used.

  2. Service Provider Handling: In most cases, the initial routing is done based on IP addresses and not the SNI. The encrypted SNI is only decrypted by the final server or a trusted intermediary within the service provider’s network.

  3. DNS-based Solutions: Sometimes, DNS is used to provide initial routing information. For example, the DNS response might include information that helps route the connection to a server that supports ECH.

Example from a Big Company: Cloudflare

Cloudflare, a major provider of Internet security and performance services, supports ECH. Here’s how they handle it:

  • Public Key Distribution: Cloudflare publishes the public keys needed for ECH via DNS, ensuring that clients can securely encrypt their Client Hello messages.
  • Initial Routing: When a client connects to a Cloudflare-protected site, the initial packets are routed based on IP addresses. Cloudflare’s network recognizes the ECH indicators and forwards the traffic to the appropriate server.
  • Decryption and Handshake: Once the traffic reaches the correct server within Cloudflare’s infrastructure, the server decrypts the Client Hello message and completes the TLS handshake, ensuring the connection is secure and private.

Cloudflare has been actively working on ECH and other privacy-enhancing technologies to improve user security and privacy on the Internet.

Learn More

Here are some resources to dive deeper into ECH and its implementation: