Although TLS can encrypt the entire communication process, there are still many privacy-sensitive parameters that have to be transmitted in plaintext during the negotiation process, the most important and problematic of which is the domain name to be accessed, i.e. SNI (Server Name Indication). There is also the ALPN extension used to inform the client of the available application layer protocols, and compromising this could lead to an attacker knowing the services supported by the server and the purpose of the connection.
The reason why such important content is exposed is not a design mistake, but because encrypting that content would prevent many servers from working properly. In general, a server often provides many services, ranging from using nginx to reverse proxy several services to CDN servers serving countless websites at the same time, and because the domain names are different, the certificates are also different.
Then when the client accesses the service, it must specify the SNI so that the server knows which certificate to return, but there is no way to encrypt the certificate before the client receives it, leaving it in an awkward position of whether to have the chicken or the egg first.
ESNI and its successor ECH are designed to remedy this problem.
Encrypted SNI
ESNI (Encrypted SNI), as its name implies, was designed to encrypt SNI and was one of the first TLS extensions proposed to solve this problem. Although this scheme is about to be deprecated, it is extremely useful for understanding its successor, ECH.
ESNI relies on another service, DNS, to distribute the key in order for the client to get the key to send the ciphertext. Before a client connects to the server using ESNI, it makes a TXT request on top of the regular A/AAAA request for the site IP to get the ESNI public key (actually the public key encoded in BASE64 and parameters like the encryption algorithm), as shown below in the request to this blog.
The client will send the encrypted SNI as an extension. Once the server receives the request, it decrypts it with the corresponding private key and uses the decrypted SNI for subsequent operations. If the decryption fails, the connection is terminated.
In addition to ensuring that the public key can be transmitted encrypted, DoH is also important in that it authenticates the DoH server, ensuring that the correct server is being accessed and not the (attacker-prepared) local network cache, thus avoiding The local cache returns an empty TXT record to prevent the client from using ESNI or returns an attacker-controlled key that allows the client to use the wrong public key for encryption.
However, there are still problems with this approach, the first is the distribution of keys, Cloudflare in the deployment of each hour will rotate the key, which can reduce the loss of key leakage, but DNS has a caching mechanism, the client is likely to get an out-of-date key, then the client can not continue to connect with ESNI. Secondly, DNS requests to websites may return several IP addresses, each representing a different CDN server, yet ESNI has only one TXT record, which may send the key to the wrong server resulting in a failed handshake.
Encrypted Client Hello
The goal of ECH (Encrypted Client Hello) is to overcome the shortcomings of ESNI, and as the name suggests, ECH has the ambition to encrypt not only SNI, but the entire Client Hello.
ECH also uses DoH for key distribution, but improves the distribution process. Compared to the ESNI server that terminates the connection after a failed decryption, the ECH server provides the client with a public key to retry the connection in order to complete the handshake.
So the question is, how to return the public key if the server still doesn’t know the SNI after decryption failure?
In fact, ECH’s Client Hello is divided into two parts, called ClientHelloOuter and ClientHelloInner, the surface and the inner parts. content that you want to access. The real content is in the ClientHelloInner, which encrypts sensitive information with a key and follows the ClientHelloOuter in an expanded form.
On the server side, the handshake is actually done by the ECH service provider (called client-facing server) rather than the service behind the domain name counterpart, which notifies the client if the decryption was successful and the correct ECH public key was sent.
Summary
ECH will be another major upgrade to TLS, this time making each connection accessible to no one but its originator and receiver, helping to further protect user privacy. While ECH is still a work in progress, as work continues, it is clear that we are one step closer to a more secure Internet.