Mozilla has announced the inclusion of support for users of the stable branch of Firefox for the ECH (Encrypted Client Hello) mechanism, which continues the development of ESNI (Encrypted Server Name Indication) technology and is designed to encrypt information about the parameters of TLS sessions, such as the requested domain name. Code for working with ECH was originally added to the Firefox 85 release, but was disabled by default. Chrome gradually began to include ECH support starting with the release of Chrome 115.
Since in addition to connecting with server Requested domain information is leaked via DNS. For full protection, in addition to ECH, you must use DNS over HTTPS or DNS over TLS to encrypt DNS traffic. Firefox will not use ECH without enabling DNS over HTTPS in the settings. You can check ECH support in your browser on this page.
One of the factors that enabled ECH support by default in Firefox was Cloudflare's inclusion of ECH support in its content delivery network a few days ago. On the practical side, since data about the requested hosts when using ECH is hidden from analysis, filtering and blocking unwanted sites using Cloudflare CDN will now require blocking the entire Cloudflare network, blocking all requests from ECH, or organizing HTTPS interception using fake root certificates on user system.
Initially, to organize work on one IP address of several HTTPS sites, the TLS extension SNI was used, in which the name of the requested host was indicated in the ClientHello message transmitted before establishing an encrypted communication channel. This feature made it possible to distribute requests across virtual hosts at an early stage of connection processing, but also made it possible on the ISP side to selectively filter HTTPS traffic and analyze which sites the user opens, which did not allow achieving complete confidentiality when using HTTPS.
To solve this problem and prevent leakage of information about the requested site, an ESNI extension was later proposed that implements data encryption with the host name. During the implementation of ESNI, it was revealed that the proposed mechanism does not cover all possible sources of host data leakage and its use is not enough to ensure complete confidentiality of HTTPS sessions. In particular, when resuming a previously established session, the domain name in clear text continued to be specified among the parameters of the PSK (Pre-Shared Key) TLS extension. In addition, efforts to implement ESNI have identified compatibility and scaling issues that have prevented widespread adoption of ESNI.
Taking into account the identified shortcomings of ESNI, a new universal ECH mechanism was developed that allows encryption of the parameters of any TLS extensions. Technically, the main difference between ECH and ESNI is that instead of individual fields, the entire ClientHello message is encrypted at once. ECH involves splitting the ClientHello into two separate messages - the encrypted ClientHelloInner message (SNI Inner) and the unencrypted underlying ClientHelloOuter message (SNI Outer). An unencrypted SNI Outer carries non-privacy data such as the TLS version and a list of ciphers used, as well as a common domain name that does not overlap with the actual name of the requested domain. For example, for all Cloudflare clients, the unencrypted SNI Outer specifies the common host "cloudflare-ech.com", but the actual name of the requested host is transmitted in the encrypted SNI Inner and is not available for analysis.
ECH also uses a different encryption key distribution scheme: public key information is transmitted in HTTPSSVC DNS records rather than TXT records. Authenticated end-to-end encryption based on the HPKE (Hybrid Public Key Encryption) mechanism is used to obtain and encrypt the key. ECH also supports secure key retransmission from the server, which can be used in the event of key rotation. server and to resolve issues with retrieving outdated keys from the DNS cache.
Source: opennet.ru
