Mozilla har meddelat att de inför stöd för mekanismen ECH (Encrypted Client Hello) för anvÀndarna av den stabila versionen av Firefox, vilket fortsÀtter att utveckla teknologin ESNI (Encrypted Server Name Indication) och syftar till att kryptera information om TLS-sessioner, sÄsom det begÀrda domÀnnamnet. Den ursprungliga koden för att stödja ECH lades till i Firefox 85, men var inaktiverad som standard. I Chrome började stöd för ECH gradvis aktiveras frÄn och med version 115.
Eftersom anslutningen till servern lÀckage av information om begÀrda domÀner sker genom DNS, krÀvs utöver ECH Àven anvÀndning av teknologin DNS över HTTPS eller DNS över TLS för att kryptera DNS-trafiken. Firefox kommer inte att anvÀnda ECH utan aktivering av DNS över HTTPS i instÀllningarna. Du kan kontrollera stöd för ECH i webblÀsaren pÄ den hÀr sidan.
En av faktorerna till att stöd för ECH aktiverades som standard i Firefox var att Cloudflare för nÄgra dagar sedan aktiverade stöd för ECH i sitt innehÄllsnÀtverk. FrÄn ett praktiskt perspektiv, eftersom data om begÀrda vÀrdar Àr dolda frÄn analys nÀr ECH anvÀnds, kommer det nu att krÀvas att blockera hela Cloudflare-nÀtverket, blockera alla förfrÄgningar med ECH eller organsera avlyssning av HTTPS med hjÀlp av falska rotcertifikat pÄ anvÀndarsystemet för att filtrera och blockera oönskade webbplatser som anvÀnder Cloudflare CDN.
Ursprungligen anvÀndes TLS-tillÀgget SNI för att möjliggöra drift av flera HTTPS-webbplatser pÄ en och samma IP-adress, dÀr namnet pÄ den begÀrda vÀrden angavs i ClientHello-meddelandet som skickades innan den krypterade kommunikationskanalen etablerades. Denna egenskap gjorde det möjligt att fördela förfrÄgningar mellan virtuella vÀrdar i det tidiga skedet av anslutningsbehandlingen, men tillÀt Àven internetleverantörer att selektivt filtrera HTTPS-trafik och analysera vilka webbplatser anvÀndaren besöker, vilket hindrade fullstÀndig konfidentialitet vid anvÀndning av HTTPS.
För att lösa detta problem och förhindra lÀckage av information om den begÀrda webbplatsen föreslogs senare en utvidgning av ESNI, som implementerar kryptering av data med namn pÄ vÀrden. Under införandet av ESNI upptÀcktes att den föreslagna mekanismen inte tÀcker alla möjliga kÀllor till datalÀckage om vÀrden, och dess tillÀmpning Àr otillrÀcklig för att sÀkerstÀlla fullstÀndig konfidentialitet vid HTTPS-sessioner. SÀrskilt vid förnyelse av en tidigare etablerad session angavs domÀnnamnet i klartext bland parametrarna för TLS-tillÀgget PSK (Pre-Shared Key). Dessutom avslöjade försöken med att implementera ESNI problem med kompatibilitet och skalbarhet, vilket hindrade spridningen av ESNI.
Med hĂ€nsyn till de identifierade bristerna utvecklades en ny universell mekanism, ECH, som tillĂ„ter kryptering av parametrar för alla TLS-tillĂ€gg. Den tekniska huvudskillnaden mellan ECH och ESNI Ă€r att hela meddelandet ClientHello krypteras istĂ€llet för separata fĂ€lt. ECH innebĂ€r att ClientHello delas upp i tvĂ„ separata meddelanden â det krypterade meddelandet ClientHelloInner (SNI Inner) och det okrypterade grundmeddelandet ClientHelloOuter (SNI Outer). I det okrypterade SNI Outer skickas icke-konfidentiell information, sĂ„som TLS-version och lista över anvĂ€nda krypteringsmetoder, liksom det övergripande domĂ€nnamnet som inte överlappar med det faktiska begĂ€rda domĂ€nnamnet. Till exempel anges den gemensamma vĂ€rden för alla Cloudflare-kunder i det okrypterade SNI Outer, "cloudflare-ech.com", medan det faktiska namnet pĂ„ den begĂ€rda vĂ€rden skickas i det krypterade SNI Inner och Ă€r inte tillgĂ€ngligt för analys.
ECH anvĂ€nder ocksĂ„ en annan nyckelutbyteschema för kryptering â information om den offentliga nyckeln överförs i DNS-poster av typen HTTPSSVC, snarare Ă€n i poster av typen TXT. För att fĂ„ och kryptera nyckeln anvĂ€nds autentiserad end-to-end-kryptering baserad pĂ„ mekanismen HPKE (Hybrid Public Key Encryption). ECH stödjer ocksĂ„ sĂ€ker Ă„teröverföring av nycklar frĂ„n servern, vilket kan tillĂ€mpas vid nyckelrotation. servern och för att lösa problem vid hĂ€mtning av förĂ„ldrade nycklar frĂ„n DNS-cachen.
KĂ€lla: opennet.ru
