„Mozilla“ paskelbė apie stabilios „Firefox“ šakos naudotojų palaikymą, skirtą ECH (Encrypted Client Hello) mechanizmui, kuris tęsia ESNI (šifruoto serverio vardo indikacijos) technologijos kūrimą ir yra skirtas informacijai apie TLS seansų parametrus šifruoti. , pvz., prašomą domeno pavadinimą. Kodas darbui su ECH iš pradžių buvo įtrauktas į „Firefox 85“ leidimą, tačiau pagal numatytuosius nustatymus buvo išjungtas. „Chrome“ palaipsniui pradėjo įtraukti ECH palaikymą, pradedant „Chrome 115“ išleidimu.
Kadangi be ryšio su serveris Prašoma domeno informacija nutekėjo per DNS. Norint visapusiškai apsaugoti, be ECH, turite naudoti DNS per HTTPS arba DNS per TLS, kad užšifruotumėte DNS srautą. „Firefox“ nenaudos ECH, jei nustatymuose neįgalinsite DNS per HTTPS. Šiame puslapyje galite patikrinti, ar naršyklėje palaikoma ECH.
Vienas iš veiksnių, įgalinusių ECH palaikymą pagal numatytuosius nustatymus „Firefox“, buvo tai, kad „Cloudflare“ prieš kelias dienas įtraukė ECH palaikymą į savo turinio pristatymo tinklą. Iš praktinės pusės, kadangi duomenys apie prašomus pagrindinius kompiuterius naudojant ECH yra paslėpti nuo analizės, nepageidaujamų svetainių filtravimo ir blokavimo naudojant Cloudflare CDN dabar reikės blokuoti visą Cloudflare tinklą, blokuoti visas ECH užklausas arba organizuoti HTTPS perėmimą naudojant netikrus šakninius sertifikatus. vartotojo sistemoje.
Iš pradžių, norint organizuoti darbą su vienu kelių HTTPS svetainių IP adresu, buvo naudojamas TLS plėtinys SNI, kuriame prieš sukuriant šifruotą ryšio kanalą buvo nurodytas prašomo pagrindinio kompiuterio pavadinimas ClientHello pranešime. Ši funkcija leido paskirstyti užklausas virtualiuose pagrindiniuose kompiuteriuose ankstyvame ryšio apdorojimo etape, bet taip pat suteikė galimybę IPT pasirinktinai filtruoti HTTPS srautą ir analizuoti, kurias svetaines vartotojas atidaro, o tai neleido pasiekti visiško konfidencialumo naudojant HTTPS.
Siekiant išspręsti šią problemą ir užkirsti kelią informacijos apie prašomą svetainę nutekėjimui, vėliau buvo pasiūlytas ESNI plėtinys, kuris įgyvendina duomenų šifravimą pagrindinio kompiuterio pavadinimu. Diegiant ESNI paaiškėjo, kad siūlomas mechanizmas neapima visų galimų pagrindinio kompiuterio duomenų nutekėjimo šaltinių ir jo panaudojimo neužtenka visiškam HTTPS seansų konfidencialumui užtikrinti. Visų pirma, atnaujinant anksčiau nustatytą seansą, domeno pavadinimas aiškiu tekstu ir toliau buvo nurodytas tarp PSK (iš anksto bendrinamo rakto) TLS plėtinio parametrų. Be to, pastangos įdiegti ESNI nustatė suderinamumo ir mastelio problemas, kurios neleido plačiai naudoti ESNI.
Atsižvelgiant į nustatytus ESNI trūkumus, buvo sukurtas naujas universalus ECH mechanizmas, leidžiantis šifruoti bet kokių TLS plėtinių parametrus. Techniniu požiūriu pagrindinis skirtumas tarp ECH ir ESNI yra tas, kad vietoj atskirų laukų visas ClientHello pranešimas užšifruojamas vienu metu. ECH apima ClientHello padalijimą į du atskirus pranešimus – šifruotą ClientHelloInner pranešimą (SNI Inner) ir nešifruotą pagrindinį ClientHelloOuter pranešimą (SNI Outer). Nešifruotame SNI išoriniame tinkle yra ne privatumo duomenų, pvz., TLS versija ir naudojamų šifrų sąrašas, taip pat bendras domeno pavadinimas, kuris nesutampa su tikruoju prašomo domeno pavadinimu. Pavyzdžiui, visiems „Cloudflare“ klientams nešifruotas SNI Outer nurodo bendrą pagrindinį kompiuterį „cloudflare-ech.com“, tačiau tikrasis užklausos prieglobos pavadinimas perduodamas užšifruotame SNI Inner ir nėra prieinamas analizei.
ECH taip pat naudoja kitokią šifravimo raktų paskirstymo schemą: viešojo rakto informacija perduodama HTTPSSVC DNS įrašuose, o ne TXT įrašuose. Raktui gauti ir užšifruoti naudojamas autentifikuotas ištisinis šifravimas, pagrįstas HPKE (hibridinio viešojo rakto šifravimo) mechanizmu. ECH taip pat palaiko saugų rakto perdavimą iš serverio, kurį galima naudoti rakto rotacijos atveju. serveris ir išspręsti problemas, susijusias su pasenusių raktų gavimu iš DNS talpyklos.
Šaltinis: opennet.ru
