Mozilla har annonsert at de aktiverer støtte for ECH-mekanismen (Encrypted Client Hello) for brukere av stabil Firefox. Dette er en fortsettelse av ESNI-teknologien (Encrypted Server Name Indication) og er utviklet for å kryptere informasjon om TLS-øktparametere, for eksempel det forespurte domenenavnet. Koden for å jobbe med ECH ble opprinnelig lagt til i utgivelsen av Firefox 85, men ble deaktivert som standard. I Chrome har ECH-støtte gradvis blitt inkludert, fra og med utgivelsen av Chrome 115.
Siden i tillegg til å koble seg til server Forespurt domeneinformasjon lekker via DNS. For full beskyttelse, i tillegg til ECH, må du bruke DNS over HTTPS eller DNS over TLS for å kryptere DNS-trafikk. Firefox vil ikke bruke ECH uten å aktivere DNS over HTTPS i innstillingene. Du kan sjekke ECH-støtte i nettleseren din på denne siden.
En av faktorene som førte til at Firefox aktiverte ECH-støtte som standard, var at Cloudflare aktiverte ECH-støtte i sitt innholdsleveringsnettverk for noen dager siden. I praksis, siden dataene om forespurte verter er skjult for analyse når man bruker ECH, vil filtrering og blokkering av uønskede nettsteder ved hjelp av Cloudflares CDN nå kreve at man blokkerer hele Cloudflare-nettverket, blokkerer alle forespørsler med ECH, eller organiserer HTTPS-avlytting ved hjelp av falske rotsertifikater på brukerens system.
Opprinnelig ble SNI TLS-utvidelsen brukt til å organisere arbeid på én IP-adresse til flere HTTPS-nettsteder, der navnet på den forespurte verten ble spesifisert i ClientHello-meldingen som ble sendt før en kryptert kommunikasjonskanal ble opprettet. Denne funksjonen gjorde det mulig å distribuere forespørsler mellom virtuelle verter på et tidlig stadium av tilkoblingsbehandlingen, men tillot også internettleverandøren å selektivt filtrere HTTPS-trafikk og analysere hvilke nettsteder brukeren åpner, noe som ikke tillot å oppnå fullstendig konfidensialitet ved bruk av HTTPS.
For å løse dette problemet og forhindre lekkasje av informasjon om det forespurte nettstedet, ble ESNI-utvidelsen senere foreslått, som implementerte kryptering av data med vertsnavnet. Under implementeringen av ESNI ble det funnet at den foreslåtte mekanismen ikke dekker alle mulige kilder til lekkasje av vertsdata, og bruken av den er utilstrekkelig til å sikre fullstendig konfidensialitet for HTTPS-økter. Spesielt når en tidligere etablert økt ble gjenopptatt, fortsatte domenenavnet i klartekst å være spesifisert blant parameterne til PSK (Pre-Shared Key) TLS-utvidelsen. I tillegg avdekket forsøk på å implementere ESNI kompatibilitets- og skaleringsproblemer som forhindret utbredt distribusjon av ESNI.
Med tanke på de identifiserte manglene ved ESNI ble det utviklet en ny universell mekanisme, ECH, som tillater kryptering av parametere for alle TLS-utvidelser. Teknisk sett er hovedforskjellen mellom ECH og ESNI at i stedet for individuelle felt, krypteres hele ClientHello-meldingen samtidig. ECH innebærer å dele ClientHello i to separate meldinger - en kryptert ClientHelloInner (SNI Inner)-melding og en ukryptert basis ClientHelloOuter (SNI Outer)-melding. Den ukrypterte SNI Outer overfører ikke-sensitive data, for eksempel TLS-versjonen og listen over chiffer som brukes, samt et felles domenenavn som ikke overlapper med det faktiske navnet på det forespurte domenet. For eksempel, for alle Cloudflare-klienter, spesifiserer den ukrypterte SNI Outer den felles verten "cloudflare-ech.com", og det faktiske navnet på den forespurte verten overføres i den krypterte SNI Inner og er ikke tilgjengelig for analyse.
ECH bruker også et annet distribusjonsskjema for krypteringsnøkler: informasjon om offentlig nøkkel overføres i HTTPSSVC DNS-oppføringer i stedet for TXT-oppføringer. Autentisert ende-til-ende-kryptering basert på HPKE-mekanismen (Hybrid Public Key Encryption) brukes til å innhente og kryptere nøkkelen. ECH støtter også sikker nøkkeloverføring fra serveren, som kan brukes ved nøkkelrotasjon. server og for å løse problemer med å hente utdaterte nøkler fra DNS-hurtigbufferen.
Kilde: opennet.ru
