Mozilla har annonceret, at de i den stabile version af Firefox vil introducere støtte til ECH (Encrypted Client Hello), som fortsætter udviklingen af teknologien ESNI (Encrypted Server Name Indication) og er designet til at kryptere oplysninger om TLS-sessioner, såsom det anmodede domænenavn. Oprindeligt blev koden til ECH tilføjet i Firefox 85, men var deaktiveret som standard. I Chrome begyndte støtten til ECH gradvist at blive aktiveret fra version 115.
Da forbindelsen til serveren lækkage af oplysninger om anmodede domæner sker via DNS, kræves der udover ECH også anvendelse af teknologien DNS over HTTPS eller DNS over TLS for at kryptere DNS-trafik. Firefox vil ikke bruge ECH uden aktivationen af DNS over HTTPS i indstillingerne. Du kan kontrollere understøttelsen af ECH i browseren på denne side.
En af grundene til, at ECH-støtte nu er aktiveret som standard i Firefox, er, at Cloudflare for få dage siden aktiverede ECH-støtte i deres indholdsleveringsnetværk. Praktisk set, da oplysningerne om anmodede værter er skjult for analyse ved brug af ECH, for at filtrere og blokere uønskede websteder, der bruger Cloudflares CDN, kræves der nu enten blokering af hele Cloudflares netværk, blokering af alle anmodninger med ECH, eller opsætning af HTTPS-interception ved hjælp af falske rodcertifikater på brugerens system.
Oprindeligt blev TLS-udvidelsen SNI anvendt for at organisere drift af flere HTTPS-websteder på én IP-adresse, hvor det anmodede værtsnavn blev angivet i ClientHello-meddelelsen, der blev sendt før etableringen af den krypterede kommunikationskanal. Denne egenskab gjorde det muligt i de tidlige faser af forbindelsesbehandlingen at fordele anmodningerne til virtuelle værter, men tillod også internetudbyderen at filtrere HTTPS-trafik selektivt og analysere, hvilke websteder brugeren besøger, hvilket ikke gjorde det muligt at opnå fuld fortrolighed ved brug af HTTPS.
For solving this problem and preventing leakage of information about the requested site, the ESNI extension, which implements encryption of hostnames, was proposed later. During the implementation of ESNI, it was discovered that the proposed mechanism does not cover all possible sources of data leakage about the host and its use is insufficient for ensuring complete confidentiality of HTTPS sessions. In particular, when resuming a previously established session, the domain name continued to be indicated in plain text among the parameters of the PSK (Pre-Shared Key) TLS extension. Additionally, attempts to implement ESNI revealed compatibility and scalability issues 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 of any TLS extensions. The main technical difference between ECH and ESNI is that, instead of separate fields, the entire ClientHello message is encrypted at once. ECH implies the separation of ClientHello into two distinct messages — the encrypted ClientHelloInner (SNI Inner) message and the unencrypted base ClientHelloOuter (SNI Outer) message. Non-confidential data such as the TLS version and the list of used ciphers, as well as the common domain name that does not overlap with the actual requested domain name, are passed in the unencrypted SNI Outer. For example, for all Cloudflare clients, the unencrypted SNI Outer specifies 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 — the information about the public key is transmitted in DNS HTTPSSVC records, rather than in TXT records. For obtaining and encrypting the key, authenticated end-to-end encryption based on the HPKE (Hybrid Public Key Encryption) mechanism is utilized. ECH also supports secure key retransmission from the server, which can be applied in cases of key rotation. serveren and to resolve issues when obtaining outdated keys from the DNS cache.
Kilde: opennet.ru
