Mozilla has announced the inclusion of support for the Encrypted Client Hello (ECH) mechanism in the stable branch of Firefox for users, continuing the development of the Encrypted Server Name Indication (ESNI) technology, which is designed to encrypt information about TLS session parameters, such as the requested domain name. Originally, the code for ECH support was added in Firefox 85 but was disabled by default. In Chrome, support for ECH has been gradually enabled, starting from Chrome 115.
Since, in addition to connecting with proxy server the leakage of information about requested domains occurs through DNS, full protection requires the use of DNS over HTTPS or DNS over TLS to encrypt DNS traffic alongside ECH. Firefox will not use ECH without enabling DNS over HTTPS in the settings. You can check for ECH support in your browser on this page.
One of the factors that led to the default activation of ECH support in Firefox was Cloudflare's recent integration of ECH support into its content delivery network. Practically speaking, since the data about requested hosts is hidden from analysis when ECH is used, filtering and blocking unwanted sites leveraging Cloudflare's CDN now requires either blocking the entire Cloudflare network, blocking all ECH requests, or intercepting HTTPS with fraudulent root certificates on the user's system.
Initially, to host multiple HTTPS sites on a single IP address, the TLS extension SNI was used, where the requested host name was included in the ClientHello message sent before establishing a secure communication channel. This feature allowed for distributing requests among virtual hosts at an early stage of connection processing, but it also enabled internet service providers to selectively filter HTTPS traffic and analyze which sites the user is accessing, thus failing to achieve full privacy while using HTTPS.
To solve this problem and prevent leakage of information about the requested site, the ESNI extension was later proposed, implementing encryption of hostnames. During the implementation of ESNI, it was found that the proposed mechanism does not cover all possible sources of data leakage about the host, and its application is insufficient to ensure full confidentiality of HTTPS sessions. In particular, when resuming a previously established session, the domain name was still openly indicated among the parameters of the TLS PSK (Pre-Shared Key) extension. Furthermore, attempts to implement ESNI revealed compatibility and scalability issues that hindered the widespread adoption of ESNI.
Considering the identified shortcomings of ESNI, a new universal mechanism ECH was developed, allowing for the encryption of any TLS extension parameters. 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 ClientHello into two separate messages — the encrypted message ClientHelloInner (SNI Inner) and the unencrypted base message ClientHelloOuter (SNI Outer). In the unencrypted SNI Outer, non-confidential data such as the TLS version and the list of supported ciphers, as well as a generic domain name that does not intersect with the actual name of the requested domain, are transmitted. For all Cloudflare clients, the unencrypted SNI Outer specifies the generic host "cloudflare-ech.com", while the actual requested host name is sent in the encrypted SNI Inner and is not available for analysis.
ECH also uses a different key distribution scheme for encryption — information about the public key is transmitted in HTTPSSVC DNS records, rather than in TXT record types. 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 case of key rotation. server and to solve issues when retrieving outdated keys from the DNS cache.
Source: opennet.ru
