Intent to Prototype: TLS Encrypted Client Hello (ECH)
Dan McArdle
Contact emails
dmca...@chromium.org, davi...@chromium.org, kenji...@chromium.orgExplainer
NoneSpecification
TLS Encrypted Client Hello (ECH) is an IETF draft (draft-ietf-tls-esni-07).Summary
We intend to prototype TLS Encrypted ClientHello (ECH) in BoringSSL. Before starting a Chrome experiment, we will follow up with an i2e.
When a TLS client connects to a server, it sends a cleartext ClientHello message containing connection parameters. This message leaks the server's name in all HTTPS connections. ECH enables clients to encrypt sensitive portions of the ClientHello, addressing this leak.
Servers opt in by publishing ECHConfig values in DNS HTTPS records (draft-ietf-dnsop-svcb-https-01).
Blink component
Internals>Network>SSLMotivation
Without ECH, potentially sensitive connection details like the server name are leaked to eavesdroppers between the client and server.
Initial public proposal
NoneSearch tags
ech, esniTAG review
Skipping TAG review because ECH does not expose any web platform APIs.
TAG review status
n/aRisks
Interoperability and Compatibility
Chrome is not the only interested party.
Edge: No signals
Firefox: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1654332)
Safari: No signals
Cloudflare: In development (https://github.com/cloudflare/go/pull/30)
Risk of breakage/regression is expected to be low/non-existent because websites need to individually opt in to ECH (see details in Activation).
Ergonomics
ECH is a network-level feature, so it does not interact with most of the web platform. Sites opting into ECH do, however, need to publish keys in HTTPS DNS records, which may require reconfiguring their DNS service.
Activation
As mentioned above, websites need to opt-into ECH by publishing keys in their HTTPS DNS records. In addition, ECH is a new TLS extension, so servers need to update their TLS stack. While the protocol is still a draft, we expect usage to be limited to early adopters. As the draft finalizes and server software and hosting providers implement it, it will be easier for sites to deploy.
Additionally, configuring keys in DNS risks mismatches with the TLS servers. ECH has a recovery mechanism, so key mismatches or rollbacks do not break the site, though the two still need to be kept in sync for best performance.
Debuggability
Prior to launching ECH, we hope to surface an “ECH was sent” boolean in the DevTools Network tab.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
ECH will be supported on all Blink platforms with the exception of Linux. At least initially, Chrome will only query HTTPS records over DNS-over-HTTPS (DoH), and Chrome on Linux does not yet support DoH.
