Security/Encrypted Client Hello

Encrypted Client Hello (ECH) is a TLS Extension which enhances the privacy of website connections by encrypting the TLS Client Hello with a public key fetched over DNS. ECH is undergoing standardization at the IETF, available as aworking group draft. ECH. Firefox has implemented support for Encrypted Client Hello since Firefox 98 (bug).

Encrypted Client Hello is an extension for TLS1.3. Clients that implement support add a new TLS extension to their Client Hello. Servers that do not implement support are required by the TLS1.3 specification to ignore the unrecognized extension. Servers that do implement support will try to process the extension and establish a connection using ECH. As well as implementing support, servers must also advertise a public key and other configuration values for use with ECH in their DNS records, using the new HTTPS resource record type.

If the client has discovered an ECH configuration for use with the server in question, the ECH extension will contain encrypted data for the initial client hello, including the SNI (Server Name Indication) value. If not, the client will randomly generate an ECH extension which the server will necessarily ignore. This latter scenario is known as ECH GREASE (Generate Random Extensions And Sustain Extensibility) and used to ensure networks and servers correctly tolerate new ECH extensions.

ECH has been carefully designed to interoperate with existing network practices. For example, if a browser has been configured by the user or administrator to trust an enterprise certificate authority (CA) which is then used to proxy TLS traffic, ECH will be securely downgraded by the proxy. This ensures that network administrators don’t need to worry about interference from ECH. Some enterprises do not use a transparent proxy and instead rely on passive SNI sniffing which is no longer possible with ECH. However, this technique has never been effective against malware or other security risks as malware is already able to spoof the SNI field.

Further Reading:

• Cloudflare’s explainer on ECH’s design.
• The IETF draft specification for ECH.

We implement support for the latest draft of Encrypted Client Hello. As is the norm, Firefox’s ECH behavior can be configured by a range of preferences which are detailed in their own section below. Enabling ECH results in Firefox sending a GREASE ECH extension for every connection (whether QUIC or TLS) and actively using ECH whenever Firefox discovers an ECH configuration for the site in question. Currently, Firefox can only fetch these ECH configurations over DoH (DNS over HTTPS), the benefits and drawbacks of which are discussed in the section below.

Dependency on DoH

ECH relies on a new type of DNS record which Firefox can currently only fetch via its DoH DNS stack. Support for fetching these records with the OS native resolver is tracked in bug1500289. Support via DoH has been prioritized because using unencrypted DNS with ECH delivers little overall benefit to user privacy.

For the vast majority of users, their native OS resolver will use unencrypted DNS to contact their local router which in turn passes their queries unencrypted on to their network provider. Fetching ECHConfigs via unencrypted DNS means that the sites the user visits are still leaked in plaintext to the network and so ECH delivers little value in this scenario.

For expert users, they may well use unencrypted local DNS but have configured their local DNS resolver to use a secure transport for reaching out across the network (e.g. with PiHole or similar). For such users, the easiest way to benefit from ECH and continue to use their local DNS resolver is to set up DNS-over-HTTPS locally. There are guides available for doing this, e.g. the instructionshere for DNSCrypt.

In the long term, we will look at adding support for fetching ECHConfigs via the system resolver, but this requires work on each OS we support and so requires sustained investment in return for limited benefit. We may also start to see wider support for DoH by default in popular self-hosted DNS packages.

UX

We don’t currently expose ECH status in the browser. See the section below on how to test ECH. However:

• Bug 1804460 tracks the work to expose ECH (and similar privacy features) in DevTools
• ECH status can be accessed via the Extension API GetSecurityInfo, see the MDN documentation.

Preferences

Note that DoH must also be enabled for ECH to be actively used. This is exposed as a user visible setting in about:preferences. See also the TRR Prefs and the DoH Prefs.

Interaction with Revocation Checking

Firefox supports various methods for checking whether certificates have been revoked including OCSP, OCSP Stapling and (experimentally) CRLite. OCSP requires querying the certificate's revocation status with the issuing CA and so leaks information about the site a user is visiting. Consequently, sites deploying ECH should also use OCSP Stapling or short lived certificates which don't involve any network communication and so improves user privacy (Cloudflare deploy OCSP Stapling universally). If sites do not use OCSP Stapling, then ECH still provides a substantial privacy benefit as OCSP responses are cached for multiple days and so the majority of site visits will be protected. In the longer term, CRLite will allow for privacy preserving revocation checking without requiring action by site operators.

Users who prefer improved privacy over the security of revocation checking can disable revocation via the browser UX in about:preferences (or in about:config by preference).

Possible Breakage

ECH GREASE adds an extension to ClientHellos which contains random data. The TLS1.3 and TLS1.2 specifications REQUIRE servers to ignore extensions they do not understand and so GREASE is unlikely to cause any issues.

When a site opts in to ECH support by serving an ECHConfig in its DNS record, it is possible for an incorrect ECHConfig to break access to the site. For example, if the ECHConfig specifies a cover name which the responding server does not have a valid TLS certificate for and ECH negotiation fails, then the connection will result in a security error.

Testing whether ECH is responsible for breakage

ECH doesn’t introduce any new error pages which are user visible. However, as with any networking change, its possible for incompatibilities to arise. When evaluating whether an issue is due to ECH, the following steps are recommended:

1. Isolate whether the issue is due to ECH, ECH GREASE or neither.
   1. Disable ECH GREASE by setting security.tls.ech.grease_probability to 0 and security.tls.ech.grease_http3 to false. Test if the issue still occurs.
   2. Disable ECH by setting network.dns.echconfig.enabled and network.dns.http3_echconfig.enabled to false. Test if the issue still occurs.
   3. If Step 1 fixed the issued, the problem is ECH GREASE. If Step 2 fixed the issue, the problem is with ECH itself. If neither fixed the issue, then the problem is very unlikely to be related to ECH.
2. If the issue is due to ECH or ECH GREASE, its then worth isolating whether the issue is specific to an implementation or common. You can do this by testing with Chrome Canary with the flag “EncryptedClientHello” set to true. If the issue also occurs with ECH enabled in Chrome and is fixed by disabling it, its likely an issue with the site or its configuration.
3. Please file a bug on Bugzilla blocking bug 1725938 with the answers to the above steps so that we can take a look. We are already aware of a limited number of sites with broken TLS servers which do not follow the specification (see below).

Testing whether ECH is working

There are various sites which can be used to test whether ECH was used in the connection:

• https://www.cloudflare.com/ssl/encrypted-sni/
• https://tls-ech.dev/
• https://defo.ie/ech-check.php

Tools like Wireshark can also be used to inspect TLS connection flows.

Known Incompatible Sites

We are aware of a very limited number of sites which do not correctly implement TLS. These sites are unable to handle TLS Client Hello messages with any unrecognised extension, despite the clear requirements in the specifications:

Servers MUST ignore unrecognized extensions.
[...]
A server receiving a ClientHello MUST correctly ignore all unrecognized cipher suites, extensions, and other parameters.

These sites do not have an ECH-specific incompatibility, they break for all new extensions they do not recognise. We’ve reached out to the site operators to inform them of the problem.

The DEfO project and the Guardian Project have implemented ECH support in a number of applications:

• OpenSSL
• curl
• nginx
• apache
• lighttpd
• HAProxy
• Conscrypt

Support is also available in Firefox and Chromium. Webkit / Safari have indicated support for ECH, but have not implemented it. Caddy has yet to make a decision.