Post

Every lock needs a key. The hard part is not always designing the lock. Sometimes it is getting the key to the person who needs it. That is the problem I look at in the third post in my CDT series on Encrypted Client Hello. cdt.org/insights/dis...

ECH is designed to close one of the last major metadata leaks in HTTPS: the website name exposed in the TLS ClientHello. But before a browser can encrypt that part of the handshake, it needs the server’s ECH configuration.

Today, that configuration usually comes from DNS. In normal network conditions, that is a clean design. In censorship environments, it is an obvious pressure point.

DNS-over-TLS can be blocked outright. DNS-over-HTTPS is harder to block cleanly because it runs over HTTPS, but it can still be identified and degraded. The result is often not a crisp failure. It is flakiness, temporary blocking, and users giving up.

That matters for ECH because a censor does not need to break the TLS handshake if it can prevent the client from obtaining the ECH configuration in the first place. The failure happens before the privacy property turns on.

This is a recurring lesson of Internet security. Cryptography is necessary, but it is not the whole system. Discovery, distribution, caching, fallback behavior, and downgrade resistance are part of the security architecture too.