I Firefox og Cloudflare er det lagt til støtte for ECH for å skjule domenet i HTTPS-trafikk

Mozilla har kunngjort at de har inkludert støtte for mekanismen ECH (Encrypted Client Hello) i den stabile versjonen av Firefox, som fortsetter utviklingen av teknologien ESNI (Encrypted Server Name Indication) og er ment for å kryptere informasjon om parametrene til TLS-økter, slik som det forespurte domenenavnet. Opprinnelig ble koden for å håndtere ECH lagt til i utgivelsen av Firefox 85, men den var deaktivert som standard. I Chrome har de begynt å gradvis aktivere ECH, med starten fra utgivelsen av Chrome 115.

Siden det i tillegg til tilkoblingen til serveren lekasje av forespurte domenedata skjer gjennom DNS, er det nødvendig med bruk av teknologien DNS over HTTPS eller DNS over TLS for å kryptere DNS-trafikken for full beskyttelse i tillegg til ECH. Firefox vil ikke bruke ECH uten at DNS over HTTPS er aktivert i innstillingene. Du kan sjekke om ECH er støttet i nettleseren din på denne siden.

En av faktorene for aktivering av støtte for ECH som standard i Firefox, var at Cloudflare for noen dager siden aktiverte støtte for ECH i sitt innholdsdistribusjonsnettverk. Praktisk talt, siden data om forespurte verter er skjult fra analyse ved bruk av ECH, vil det nå være nødvendig å blokkere hele Cloudflare-nettverket, blokkere alle forespørsel med ECH, eller organisere avlytting av HTTPS ved hjelp av falske rotsertifikater på brukerens system for å filtrere og blokkere uønskede nettsteder som bruker Cloudflare CDN.

Opprinnelig ble TLS-utvidelsen SNI brukt for å muliggjøre drift av flere HTTPS-nettsteder på én IP-adresse, der navnet på den forespurte verten ble angitt i ClientHello-meldingen, som ble sendt før opprettelsen av den krypterte kommunikasjonskanalen. Denne funksjonen ga mulighet til å fordele forespørslene blant virtuelle verter på et tidlig stadium av tilkoblingsbehandlingen, men tillot også internettleverandøren å selektivt filtrere HTTPS-trafikk og analysere hvilke nettsteder brukeren besøker, noe som ikke ga full konfidensialitet ved bruk av HTTPS.

For addressing this issue and preventing leakage of information regarding the requested site, the ESNI extension was later proposed, which implements encryption of data including the hostname. During the deployment of ESNI, it was discovered that the proposed mechanism does not cover all possible sources of data leakage about the host, and its application is insufficient for ensuring complete confidentiality of HTTPS sessions. In particular, when resuming a previously established session, the domain name was still indicated in plain text among the parameters of the TLS extension PSK (Pre-Shared Key). Moreover, attempts to implement ESNI revealed compatibility and scalability problems that hindered its widespread adoption.

Considering the identified shortcomings of ESNI, a new universal mechanism called ECH was developed, allowing for the encryption of parameters for 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 implies the separation of ClientHello into two distinct messages — the encrypted ClientHelloInner (SNI Inner) and the unencrypted base message ClientHelloOuter (SNI Outer). Non-confidential data such as the TLS version and the list of ciphers used, as well as a common domain name that does not overlap with the actual requested domain name, are transmitted in the unencrypted SNI Outer. For all Cloudflare clients, for instance, the unencrypted SNI Outer indicates the common host "cloudflare-ech.com", while 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 key distribution scheme for encryption — information about the public key is transmitted in DNS records of type HTTPSSVC instead of in 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 employed when rotating keys. serveren and for addressing issues when retrieving outdated keys from the DNS cache.

Kilde: opennet.ru