CarderPlanet
Professional
- Messages
- 2,552
- Reaction score
- 684
- Points
- 83
Mozilla has announced the inclusion of support for the ECH (Encrypted Client Hello) mechanism for users of the stable Firefox branch, which continues the development of ESNI (Encrypted Server Name Indication) technology and is designed to encrypt information about TLS session parameters, such as the requested domain name. Initially, the code for working with ECH was added in the Firefox 85 release, but was disabled by default. In Chrome, ECH support began to be gradually included, starting with the release of Chrome 115.
Since, in addition to connecting to the server, information about the requested domains is leaked via DNS, for full protection, in addition to ECH, it is necessary to use DNS over HTTPS or DNS over TLS technology to encrypt DNS traffic. Firefox will not use ECH without enabling DNS over HTTPS in the settings. You can check ECH support in the browser on this page.
One of the factors that enabled Firefox's default ECH support was Cloudflare's inclusion of ECH support in its content delivery network a few days ago. On the practical side, since data about requested hosts is hidden from analysis when using ECH, filtering and blocking unwanted sites that use the Cloudflare CDN will now require blocking the entire Cloudflare network, blocking all requests from ECH, or organizing HTTPS interception using fake root certificates on the user's system.
Initially, to organize work on the same IP address of several HTTPS sites, the TLS extension SNI was used, in which the name of the requested host was specified in the ClientHello message transmitted before the encrypted communication channel was installed. This feature made it possible to distribute requests across virtual hosts at an early stage of connection processing, but also allowed the Internet provider to selectively filter HTTPS traffic and analyze which sites the user opens, which did not allow for complete confidentiality when using HTTPS.
To solve this problem and avoid leakage of information about the requested site, the ESNI extension was later proposed, which implements encryption of data 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 application is not sufficient to ensure complete confidentiality of HTTPS sessions. In particular, when resuming a previously established session, the plaintext domain name continued to be specified among the parameters of the PSK (Pre-Shared Key) TLS extension. In addition, attempts to implement ESNI revealed compatibility and scaling issues that prevented the widespread adoption of ESNI.
Taking into account the identified shortcomings of ESNI, a new universal ECH mechanism was developed that allows encryption of parameters of any TLS extensions. Technically, the main difference between ECH and ESNI is that instead of separate fields, the entire ClientHello message is encrypted at once. ECH implies two types of ClientHello messages : an encrypted ClientHelloInner message and an unencrypted ClientHelloOuter base message. If the server supports ECH and was able to decrypt the ClientHelloInner, then it continues to use this type for the TLS session. Otherwise, data is taken from ClientHelloOuter.
ECH also uses a different key distribution scheme for encryption - information about the public key is transmitted to the HTTPSSVC DNS record, and not to records with the TXT type. 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 on the server and to solve problems when getting outdated keys from the DNS cache.
Since, in addition to connecting to the server, information about the requested domains is leaked via DNS, for full protection, in addition to ECH, it is necessary to use DNS over HTTPS or DNS over TLS technology to encrypt DNS traffic. Firefox will not use ECH without enabling DNS over HTTPS in the settings. You can check ECH support in the browser on this page.
One of the factors that enabled Firefox's default ECH support was Cloudflare's inclusion of ECH support in its content delivery network a few days ago. On the practical side, since data about requested hosts is hidden from analysis when using ECH, filtering and blocking unwanted sites that use the Cloudflare CDN will now require blocking the entire Cloudflare network, blocking all requests from ECH, or organizing HTTPS interception using fake root certificates on the user's system.
Initially, to organize work on the same IP address of several HTTPS sites, the TLS extension SNI was used, in which the name of the requested host was specified in the ClientHello message transmitted before the encrypted communication channel was installed. This feature made it possible to distribute requests across virtual hosts at an early stage of connection processing, but also allowed the Internet provider to selectively filter HTTPS traffic and analyze which sites the user opens, which did not allow for complete confidentiality when using HTTPS.
To solve this problem and avoid leakage of information about the requested site, the ESNI extension was later proposed, which implements encryption of data 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 application is not sufficient to ensure complete confidentiality of HTTPS sessions. In particular, when resuming a previously established session, the plaintext domain name continued to be specified among the parameters of the PSK (Pre-Shared Key) TLS extension. In addition, attempts to implement ESNI revealed compatibility and scaling issues that prevented the widespread adoption of ESNI.
Taking into account the identified shortcomings of ESNI, a new universal ECH mechanism was developed that allows encryption of parameters of any TLS extensions. Technically, the main difference between ECH and ESNI is that instead of separate fields, the entire ClientHello message is encrypted at once. ECH implies two types of ClientHello messages : an encrypted ClientHelloInner message and an unencrypted ClientHelloOuter base message. If the server supports ECH and was able to decrypt the ClientHelloInner, then it continues to use this type for the TLS session. Otherwise, data is taken from ClientHelloOuter.
ECH also uses a different key distribution scheme for encryption - information about the public key is transmitted to the HTTPSSVC DNS record, and not to records with the TXT type. 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 on the server and to solve problems when getting outdated keys from the DNS cache.
