Intent to Prototype: TLS Encrypted Client Hello (ECH)

298 views
Skip to first unread message

Dan McArdle

unread,
Oct 15, 2020, 5:12:12 PMOct 15
to blink-dev

Contact emails

dmca...@chromium.orgdavi...@chromium.orgkenji...@chromium.org

Explainer

None

Specification

TLS Encrypted Client Hello (ECH) is an IETF draft (draft-ietf-tls-esni-07).

TLS ECH Design Doc


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>SSL

Motivation

Without ECH, potentially sensitive connection details like the server name are leaked to eavesdroppers between the client and server.


Initial public proposal

None

Search tags

echesni

TAG review

Skipping TAG review because ECH does not expose any web platform APIs.


TAG review status

n/a

Risks

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)?

No.

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.

Is this feature fully tested by web-platform-tests?

No

Tracking bug

https://crbug.com/1091403

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/6196703843581952

Reply all
Reply to author
Forward
0 new messages