Mozilla announced that it would replace the use of ESNI by ECH (Encrypted Client Hello) in Firefox 85 (version that is scheduled to be released on January 26) to encrypt the information of the parameters of the TLS session, such as the requested domain name.
Firefox mentions that ECH continues to evolve from ESNI and it is in the draft stage to become an IETF standard. To organize work on an IP address of several HTTPS sites, a TLS SNI extension was developed at the same time, which passes the host name in clear text in the ClientHello message, transmitted before the encrypted communication channel was installed.
Two years ago, we announced experimental support for the Encrypted Server Name Indication (ESNI) extension that protects privacy in Firefox Nightly. The TLS Server Name Indication (SNI) extension enables server and certificate selection by transmitting a clear text copy of the server’s host name in the TLS client hello message.
This represents a privacy leak similar to DNS, and just as DNS-over-HTTPS prevents DNS queries from exposing the hostname to observers along the path, ESNI attempts to prevent hostname leaks from the protocol TLS link.
This feature makes it possible to selectively filter HTTPS traffic and analyze which sites the user opens, which does not allow to achieve complete confidentiality when using HTTPS.
To prevent information leakage about the requested site, several years ago an ESNI extension was developed, which implements data encryption with a domain name (in addition to SNI, DNS can also be a source of information leakage, therefore, in addition to ESNI, you need to use DNS over HTTPS or DNS over TLS technology). In the course of attempts to implement ESNI, it was found that the proposed mechanism is not sufficient to guarantee the complete confidentiality of HTTPS sessions.
In particular, when resuming a previously established session, the domain name in clear text toseems between the parameters of the TLS PSK extension (Pre-Shared Key), that is, the encryption of the SNI fields was not enough and it was necessary to create an ESNI analog for PSK and in the future, possibly for other fields. Additionally, attempts to implement ESNI have identified compatibility and scaling issues,
In response to the need to encrypt the parameters of any TLS extension, a universal ECH mechanism was proposed, whose main difference from ESNI is that instead of a separate field, the entire ClientHello message is encrypted.
ECH involves two types of ClientHello messages: an encrypted ClientHelloInner message and an unencrypted base ClientHelloOuter message, plus if the server supports ECH and was able to decrypt ClientHelloInner, continue to use this type for the TLS session. Otherwise, the data is taken from ClientHelloOuter.
In conclusion, ECH is an exciting and robust evolution of ESNI, and Firefox will come to support the protocol. We are working hard to make sure it is interoperable and can be deployed at scale, and we are eager for users to realize the privacy benefits of this feature.
ECH also uses a different key distribution scheme for encryption: Public key information is transmitted in the DNS HTTPSSVC record and not in the TXT record. Authenticated end-to-end encryption based on Hybrid Public Key Encryption (HPKE) is used to obtain and encrypt the key. ECH also supports the secure relay of keys from the server, which can be used in the event of key rotation on the server and to resolve problems with obtaining stale keys from the DNS cache.
Further, we can point out the decision to enable by default in Firefox 86 compatibility with AVIF image format (AV1 Image Format), which uses intra-frame compression technologies from the AV1 video encoding format. The container for distributing compressed data in AVIF is completely similar to HEIF.
Source: https://blog.mozilla.org
