Mozilla anoncis la inkludon de subteno por uzantoj de la stabila branĉo de Firefox por la mekanismo ECH (Encrypted Client Hello), kiu daŭrigas la evoluon de ESNI (Encrypted Server Name Indication) teknologio kaj estas desegnita por ĉifri informojn pri la parametroj de TLS-sesioj. , kiel la petita domajna nomo. Kodo por labori kun ECH estis origine aldonita al la Firefox 85 eldono, sed estis malŝaltita defaŭlte. Chrome iom post iom komencis inkluzivi ECH-subtenon ekde la liberigo de Chrome 115.
Ĉar krom konektiĝi kun servilo Petitaj domajnaj informoj estas likitaj per DNS. Por plena protekto, krom ECH, vi devas uzi DNS super HTTPS aŭ DNS super TLS por ĉifri DNS-trafikon. Firefox ne uzos ECH sen ebligi DNS super HTTPS en la agordoj. Vi povas kontroli ECH-subtenon en via retumilo sur ĉi tiu paĝo.
Unu el la faktoroj kiuj ebligis ECH-subtenon defaŭlte en Fajrovulpo estis la inkludo de Cloudflare de ECH-subteno en sia enhavlivera reto antaŭ kelkaj tagoj. En la praktika flanko, ĉar datumoj pri la petitaj gastigantoj dum uzado de ECH estas kaŝitaj de analizo, filtri kaj bloki nedeziratajn retejojn uzante Cloudflare CDN nun postulos bloki la tutan Cloudflare-reton, bloki ĉiujn petojn de ECH aŭ organizi HTTPS-interkapton per falsaj radikaj atestiloj. sur uzantsistemo.
Komence, por organizi laboron sur unu IP-adreso de pluraj HTTPS-ejoj, oni uzis la TLS-etendon SNI, en kiu la nomo de la petita gastiganto estis indikita en la ClientHello-mesaĝo transdonita antaŭ ol establi ĉifritan komunikadkanalon. Ĉi tiu funkcio ebligis distribui petojn tra virtualaj gastigantoj en frua stadio de konektpretigo, sed ankaŭ ebligis ĉe la ISP-flanko selekteme filtri HTTPS-trafikon kaj analizi kiujn retejojn la uzanto malfermas, kio ne ebligis atingi kompletan konfidencon dum uzado. HTTPS.
Por solvi ĉi tiun problemon kaj malhelpi elfluadon de informoj pri la petita retejo, poste estis proponita ESNI-etendo, kiu efektivigas datuman ĉifradon kun la gastiga nomo. Dum la efektivigo de ESNI, estis rivelita, ke la proponita mekanismo ne kovras ĉiujn eblajn fontojn de gastiganta datuma elfluo kaj ĝia uzo ne sufiĉas por certigi kompletan konfidencon de HTTPS-sesioj. Aparte, dum rekomencado de antaŭe establita sesio, la domajna nomo en klara teksto daŭre estis specifita inter la parametroj de la PSK (Pre-Shared Key) TLS-etendo. Krome, laboroj por efektivigi ESNI identigis kongruecon kaj skalajn problemojn kiuj malhelpis ĝeneraligitan adopton de ESNI.
Konsiderante la identigitajn mankojn de ESNI, nova universala ECH-mekanismo estis evoluigita, kiu permesas ĉifradon de la parametroj de iuj TLS-etendaĵoj. Teknike, la ĉefa diferenco inter ECH kaj ESNI estas, ke anstataŭ individuaj kampoj, la tuta ClientHello-mesaĝo estas ĉifrita samtempe. ECH implikas dividi la ClientHello en du apartajn mesaĝojn - la ĉifritan ClientHelloInner-mesaĝon (SNI Inner) kaj la neĉifritan subesta ClientHelloOuter-mesaĝon (SNI Outer). Neĉifrita SNI Ekstera portas ne-privatecajn datumojn kiel ekzemple la TLS-versio kaj listo de ĉifroj uzitaj, same kiel komuna domajna nomo kiu ne interkovras kun la fakta nomo de la petita domajno. Ekzemple, por ĉiuj Cloudflare-klientoj, la neĉifrita SNI Ekstera precizigas la komunan gastiganton "cloudflare-ech.com", sed la fakta nomo de la petita gastiganto estas elsendita en la ĉifrita SNI Interna kaj ne estas havebla por analizo.
ECH ankaŭ uzas malsaman skemon por ĉifraj ŝlosiloj: informoj pri publika ŝlosilo estas transdonitaj per HTTPSSVC DNS-registroj anstataŭ TXT-registroj. Aŭtentikigita fin-al-fina ĉifrado bazita sur la mekanismo HPKE (Hibrida Publika Ŝlosilo-Ĉifrado) estas uzata por akiri kaj ĉifri la ŝlosilon. ECH ankaŭ subtenas sekuran ŝlosilretransdonon de la servilo, kiu povas esti uzata en kazo de ŝlosilrotacio. servilo kaj por solvi problemojn pri prenado de malmodernaj ŝlosiloj el la DNS-kaŝmemoro.
fonto: opennet.ru
