12
edits
Security/Encrypted Client Hello: Difference between revisions
Update ECH page to reflect latest changes in Firefox 129
(Update section titles) |
(Update ECH page to reflect latest changes in Firefox 129) |
||
| Line 16: | Line 16: | ||
==== ECH in Firefox ==== | ==== ECH in Firefox ==== | ||
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 | 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. | ||
===== Dependency on DoH ===== | ===== Dependency on DoH ===== | ||
ECH | Originally, Firefox required DoH to be enabled in order for ECH to function. Since Firefox 129, Firefox can fetch the necessary information via the OS DNS Resolver to enable ECH, allowing ECH to be used in more circumstances. Due a blocking bug with the MacOS DNS integration, MacOS still requires DoH to be enabled for ECH to be used, the work to fix this is tracked in [https://bugzilla.mozilla.org/show_bug.cgi?id=1882856 1882856]. | ||
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 | 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 less value in this scenario. For this reason, we recommend the use of DoH (whether with a self-hosted or external DoH service) in order to benefit fully from the privacy protections of ECH. | ||
For | |||
===== UX ===== | ===== UX ===== | ||
| Line 94: | Line 90: | ||
|} | |} | ||
Note that DoH | Note that ECH is most effective when DoH is used. This is exposed as a user visible setting in <code>about:preferences</code>. See also the [https://wiki.mozilla.org/Trusted_Recursive_Resolver TRR Prefs] and the [https://wiki.mozilla.org/Security/DNS_Over_HTTPS DoH Prefs]. | ||
===== Enterprise Policies ===== | |||
Firefox 127 and later support the [https://mozilla.github.io/policy-templates/#disableencryptedclienthello DisableEncryptedClientHello] Enterprise policy which administrators can use to disable ECH for devices they manage. | |||
===== Interaction with Revocation Checking ===== | ===== Interaction with Revocation Checking ===== | ||
| Line 100: | Line 100: | ||
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. | 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). | 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). | ||
==== Testing ECH and Reporting Bugs ==== | ==== Testing ECH and Reporting Bugs ==== | ||