Mozilla teatas, et Firefoxi stabiilse haru kasutajatele on aktiveeritud ECH (Encrypted Client Hello) mehhanismi tugi, mis jätkab ESNI (Encrypted Server Name Indication) tehnoloogia arengut ja on mõeldud TLS-seansside parameetrite (nt nõutava domeeninime) teabe krüpteerimiseks. ECH toega töötamise kood lisati algselt Firefoxi versiooni 85, kuid see oli vaikimisi keelatud. Chromes hakati ECH tuge järk-järgult lubama alates versioonist Chrome 115.
Kuna domeeninimede kohta saadetud teave lekib läbi DNS-i, on ECH täielikuks kaitseks vajalik rakendada DNS over HTTPS või DNS over TLS tehnoloogiat DNS-liikluse krüpteerimiseks. Firefox ei kasuta ECH-d, kui DNS over HTTPS seadistustes ei ole lubatud. ECH-i toimet kontrollimiseks brauseris saab külastada seda lehte. serverilt Ehitus, mis lubab ECH tuge, saidi ühendamisel Cloudflare'i, on oluline, et DNS-i info piirdub sõnumitega, mis on rakendamisel kehtestatud.
Üks põhjusi, miks ECH toetus Firefoxis vaikimisi aktiveeriti, oli Cloudflare'i otsus, mis tehti paar päeva tagasi, et aktiveerida ECH oma sisuhaldusvõrgus. Praktikas, kuna nõutud hostide andmed on ECH kasutamisel analüüsimiseks varjatud, siis sobivatele saitidele juurdepääsu filtreerimiseks ja blokeerimiseks, mis kasutavad Cloudflare'i CDN-i, on nüüd vajalik kas tervet Cloudflare'i võrku blokeerida, kõik ECH-i päringud blokeerida või korraldada HTTPS-i pealtkuulamine valejuursertifikaatide abil kasutaja süsteemis.
Alguses kasutati sama IP-aadressi all mitme HTTPS-saiti korraldamiseks TLS-i laiendust SNI, kus nõutud hosti nimi oli märgitud ClientHello sõnumis, mis edastati enne krüpteeritud andmekanali loomist. See omadus võimaldas varasema etapis ühenduse töötlemist jaotus- ning analüüsida, milliseid saite kasutaja avab, mis ei võimaldanud saavutada täielikku konfidentsiaalsust HTTPS-i kasutamisel.
Käesoleva probleemi lahendamiseks ja nõutud veebisaidi teabe leketeksi vältimiseks pakuti hiljem välja ESNI laiendus, mis rakendab hostinime andmete krüpteerimist. ESNI rakendamise protsessis selgus, et pakutud mehhanism ei kata kõiki võimalikke andmeleketallikaid hostist ning selle rakendamine ei ole piisav HTTPS seansside täieliku konfidentsiaalsuse tagamiseks. Eelkõige varasemalt loodud seansi taastamisel jätkus domeeninime edastamine selgesti TLS-i laieharudega PSK (Eelnevalt jagatud võtme) parameetrites. Lisaks tõid ESNI rakendamise katsed esile ühilduvuse ja skaleeritavuse probleemid, mis takistasid ESNI ulatuslikku levikut.
Arvestades ESNI tuvastatud puudusi, töötati välja uus universaalne mehhanism ECH, mis võimaldab mis tahes TLS-i laieharude parameetrite krüpteerimist. Tehniliselt on ECH-i peamine erinevus ESNI-st see, et eraldi väljade asemel krüpteeritakse kogu ClientHello sõnum korraga. ECH eristab ClientHello kahte eraldi sõnumisse - krüpteeritud sõnum ClientHelloInner (SNI Inner) ja krüpteerimata põhifail ClientHelloOuter (SNI Outer). Krüpteerimata SNI Outer edastab konfidentsiaalsust mittepuudutavaid andmeid, näiteks TLS-i versioon ja kasutatavate krüpteerimiste nimekiri, samuti üldise domeeninime, mis ei ühti tegeliku nõutud domeeninimega. Näiteks kõikide Cloudflare'i klientide puhul edastatakse krüpteerimata SNI Outer'is ühine host 'cloudflare-ech.com', samas kui tegelik nõutud hostinimi edastatakse krüpteeritud SNI Inner ja on analüüsimiseks kättesaamatu.

ECH kasutab ka teistsugust võtmevahetusmehhanismi krüpteerimiseks - avaliku võtme teave edastatakse DNS-i kirjetes HTTPSSVC, mitte TXT-tüüpi kirjetes. Võtme saamiseks ja krüpteerimiseks rakendatakse autentitud lõpp-otsas krüpteerimist, mis põhineb HPKE (Hübriid Avaliku Võtme Krüpteerimise) mehhanismil. ECH toetab ka võtme turvalist edastamist serverist, mis võib rakenduda võtme rotatsiooni korral. serveris ja probleemide lahendamiseks vanade võtmete saamisel DNS-i vahemälust.
Allikas: opennet.ru
