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.

China is the clearest example. The Great Firewall has a long history of DNS injection and poisoning. Encrypted DNS changes the mechanics, but not the basic incentive to control the discovery path.

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.

The natural question is whether ECH configurations need to be tied so tightly to DNS. DNS currently handles both distribution and authentication. If those functions can be separated, ECH configs could be distributed through other paths and still verified.