https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox/ Mozilla Menu * Internet Health * Technology * Give Download Firefox Mozilla Security Blog * Search this site [ ] Search Categories: Crypto Engineering Security TLS Encrypted Client Hello: the future of ESNI in Firefox Kevin Jacobs January 7, 2021 Background Two years ago, we announced experimental support for the privacy-protecting Encrypted Server Name Indication (ESNI) extension in Firefox Nightly. The Server Name Indication (SNI) TLS extension enables server and certificate selection by transmitting a cleartext copy of the server hostname in the TLS Client Hello message. This represents a privacy leak similar to that of DNS, and just as DNS-over-HTTPS prevents DNS queries from exposing the hostname to on-path observers, ESNI attempts to prevent hostname leaks from the TLS handshake itself. Since publication of the ESNI draft specification at the IETF, analysis has shown that encrypting only the SNI extension provides incomplete protection. As just one example: during session resumption, the Pre-Shared Key extension could, legally, contain a cleartext copy of exactly the same server name that is encrypted by ESNI. The ESNI approach would require an encrypted variant of every extension with potential privacy implications, and even that exposes the set of extensions advertised. Lastly, real-world use of ESNI has exposed interoperability and deployment challenges that prevented it from being enabled at a wider scale. Enter Encrypted Client Hello (ECH) To address the shortcomings of ESNI, recent versions of the specification no longer encrypt only the SNI extension and instead encrypt an entire Client Hello message (thus the name change from "ESNI" to "ECH"). Any extensions with privacy implications can now be relegated to an encrypted "ClientHelloInner", which is itself advertised as an extension to an unencrypted "ClientHelloOuter". Should a server support ECH and successfully decrypt, the "Inner" Client Hello is then used as the basis for the TLS connection. This is explained in more detail in Cloudflare's excellent blog post on ECH. ECH also changes the key distribution and encryption stories: A TLS server supporting ECH now advertises its public key via an HTTPSSVC DNS record, whereas ESNI used TXT records for this purpose. Key derivation and encryption are made more robust, as ECH employs the Hybrid Public Key Encryption specification rather than defining its own scheme. Importantly, ECH also adds a retry mechanism to increase reliability with respect to server key rotation and DNS caching. Where ESNI may currently fail after receiving stale keys from DNS, ECH can securely recover, as the client receives updated keys directly from the server. ECH in Firefox 85 In keeping with our mission of protecting your privacy online, Mozilla is actively working with Cloudflare and others on standardizing the Encrypted Client Hello specification at the IETF. Firefox 85 replaces ESNI with ECH draft-08, and another update to draft-09 (which is targeted for wider interoperability testing and deployment) is forthcoming. Users that have previously enabled ESNI in Firefox may notice that the about:config option for ESNI is no longer present. Though we recommend that users wait for ECH to be enabled by default, some may want to enable this functionality earlier. This can be done in about:config by setting network.dns.echconfig.enabled and network.dns.use_https_rr_as_altsvc to true, which will allow Firefox to use ECH with servers that support it. While ECH is under active development, its availability may be intermittent as it requires both the client and server to support the same version. As always, settings exposed only under about:config are considered experimental and subject to change. For now, Firefox ESR will continue to support the previous ESNI functionality. In conclusion, ECH is an exciting and robust evolution of ESNI, and support for the protocol is coming to Firefox. We're working hard to make sure that it is interoperable and deployable at scale, and we're eager for users to realize the privacy benefits of this feature. Tags: NSS, Security, TLS Browse fast. Browse free. Download Firefox Previous article Design of the CRLite Infrastructure December 1, 2020 More articles in "Crypto Engineering" * Design of the CRLite Infrastructure December 1, 2020 * Preloading Intermediate CA Certificates into Firefox November 13, 2020 * Performance Improvements via Formally-Verified Cryptography in Firefox July 6, 2020 * Expanding Client Certificates in Firefox 75 April 14, 2020 * CRLite: Speeding Up Secure Browsing January 21, 2020 Recent articles * Design of the CRLite Infrastructure December 1, 2020 * Measuring Middlebox Interference with DNS Records November 17, 2020 * Firefox 83 introduces HTTPS-Only Mode November 17, 2020 * Preloading Intermediate CA Certificates into Firefox November 13, 2020 * Firefox 79 includes protections against redirect tracking August 4, 2020 Keep up with all things Firefox. Your e-mail address [ ] Country [- select - ] Language [English ] (*) HTML ( ) Text [ ] I'm okay with Mozilla handling my info as explained in this Privacy Policy. Sign up now We will only send you Mozilla-related information. Thanks! If you haven't previously confirmed a subscription to a Mozilla-related newsletter you may have to do so. Please check your inbox or your spam filter for an e-mail from us. Mozilla Mozilla * About * Contact Us * Donate * + Twitter (@mozilla) + Instagram (@mozillagram) Firefox * Download Firefox * Desktop * Mobile * Features * Beta, Nightly, Developer Edition * + Twitter (@firefox) + YouTube (firefoxchannel) * Website Privacy Notice * Cookies * Legal Visit Mozilla Corporation's not-for-profit parent, the Mozilla Foundation. Portions of this content are (c)1998-2021 by individual contributors. Content available under a Creative Commons license.