In this video, I will discuss the new TLS extension Encrypted Client Hello which is a new mechanism to encrypt the entire client hello, very interesting and elegantly design but I have my few reservations and criticisms. Let us discuss.

Intro 0:00

Classic TLS with SNI 7:00

ESNI 9:30

ECH 12:30

Limitations and Problems 21:00

Let's say the backend server hosts example.com with the cert of example.com and let us call this the “real” SNI. To support ECH, the same server should also host a client facing cert, lets call it server-ech.com with corresponding server-ech.com cert. So your server IP address is hosting two domains. example.com and ( server-ech.com just to support ech)

So when you perform an oDoH/DoH query looking for example.com you will get back the IP address of example.com, (which is the same ip address as server-ech.com), you will also get the ephemeral public key of example.com from the HTTPSSVC DNS record. This will be used to encrypt the inner client hello, and finally, you will get a record of the front-facing server domain name which is server-ech.com.

The client prepares the TLS ECH, it builds the outer client hello with the SNI value as server-ech.com, and the inner client hello with the real SNI (example.com) along side ALPN and other stuff..

It then uses the public key of example.com retrieved from the HTTPS DNS record to encrypt the inner client hello. The client sends the ECH.

Server receives the ECH, and attempts to decrypt the inner client hello with the corresponding ephemeral private key, if it succeeds it then completes the server hello and key exchange as normal.

if it fails to decrypt the inner client hello with its own private key that means the public key used, was stale, outdated, bad etc.. . The client then uses the outer client hello and it checks, do I have server-ech.com, yes I do have a cert for that, let me just finish the key exchange and server hello with that instead, and btw, here is my REAL public key for example.com so you can use it for future ECHs. the public key is going to be encrypted for sure (that was something not clear in the article) because its TLS 1.3 and things are immediately encrypted from the server. The client then finishes the handshake and finds out the public key and immediately terminate the connection and re-establishes it with brand new encrypted inner client hello that uses the new server public key which we know this time its going to work ..

I can image getting into an infinite loop if the server accidentally gave a wrong public key. also some cons of ECH comes to mind is the larger client hello + the additional backend management to host that client facing server and cert. Also another question, what If I’m hosting 100 domains on my single IP address, do I get a single ephmeral public key for ECH? or is it per domain? and how does my server know what private key to use to decrypt, does it just try them one by one? or is there an indication to which public key was used to encrypt the inner client hello.. (I’m guessing there is )

https://blog.cloudflare.com/encrypted-client-hello/

Can China Block the New Encrypted Client Hello TLS Extension? Let us Discuss

The Backend Engineering Show with Hussein Nasser

Can China Block the New Encrypted Client Hello TLS Extension? Let us Discuss