Mozilla har meddelat införandet av stöd för anvÀndare av den stabila grenen av Firefox för mekanismen ECH (Encrypted Client Hello), som fortsÀtter utvecklingen av ESNI-teknologi (Encrypted Server Name Indication) och Àr utformad för att kryptera information om parametrarna för TLS-sessioner , till exempel det begÀrda domÀnnamnet. Koden för att arbeta med ECH lades ursprungligen till i Firefox 85-versionen, men var inaktiverad som standard. Chrome började gradvis inkludera ECH-stöd frÄn och med lanseringen av Chrome 115.
Eftersom det förutom att ha kontakt med server BegÀrd domÀninformation lÀcker ut via DNS. För fullstÀndigt skydd mÄste du, utöver ECH, anvÀnda DNS över HTTPS eller DNS över TLS för att kryptera DNS-trafik. Firefox anvÀnder inte ECH utan att aktivera DNS över HTTPS i instÀllningarna. Du kan kontrollera ECH-stödet i din webblÀsare pÄ den hÀr sidan.
En av faktorerna som aktiverade ECH-stöd som standard i Firefox var Cloudflares inkludering av ECH-stöd i sitt innehÄllsleveransnÀtverk för nÄgra dagar sedan. PÄ den praktiska sidan, eftersom data om de begÀrda vÀrdarna nÀr du anvÀnder ECH Àr dold frÄn analys, kommer filtrering och blockering av oönskade webbplatser med Cloudflare CDN nu att krÀva blockering av hela Cloudflare-nÀtverket, blockering av alla förfrÄgningar frÄn ECH eller organisera HTTPS-avlyssning med falska rotcertifikat pÄ anvÀndarsystemet.
Inledningsvis, för att organisera arbetet pÄ en IP-adress för flera HTTPS-platser, anvÀndes TLS-tillÀgget SNI, dÀr namnet pÄ den begÀrda vÀrden indikerades i ClientHello-meddelandet som skickades innan en krypterad kommunikationskanal etablerades. Den hÀr funktionen gjorde det möjligt att distribuera förfrÄgningar över virtuella vÀrdar i ett tidigt skede av anslutningsbehandlingen, men gjorde det ocksÄ möjligt pÄ ISP-sidan att selektivt filtrera HTTPS-trafik och analysera vilka webbplatser anvÀndaren öppnar, vilket inte gjorde det möjligt att uppnÄ fullstÀndig konfidentialitet vid anvÀndning HTTPS.
För att lösa detta problem och förhindra lÀckage av information om den begÀrda platsen, föreslogs senare en ESNI-tillÀgg som implementerar datakryptering med vÀrdnamnet. Under implementeringen av ESNI avslöjades det att den föreslagna mekanismen inte tÀcker alla möjliga kÀllor till vÀrddatalÀckage och att anvÀndningen inte rÀcker för att sÀkerstÀlla fullstÀndig sekretess för HTTPS-sessioner. I synnerhet nÀr en tidigare etablerad session Äterupptogs fortsatte domÀnnamnet i klartext att specificeras bland parametrarna för PSK (Pre-Shared Key) TLS-tillÀgget. Dessutom har anstrÀngningar för att implementera ESNI identifierat kompatibilitets- och skalningsproblem som har förhindrat en utbredd anvÀndning av ESNI.
Med hÀnsyn till de identifierade bristerna hos ESNI utvecklades en ny universell ECH-mekanism som tillÄter kryptering av parametrarna för alla TLS-tillÀgg. Tekniskt sett Àr den största skillnaden mellan ECH och ESNI att istÀllet för enskilda fÀlt krypteras hela ClientHello-meddelandet pÄ en gÄng. ECH innebÀr att dela upp ClientHello i tvÄ separata meddelanden - det krypterade ClientHelloInner-meddelandet (SNI Inner) och det okrypterade underliggande ClientHelloOuter-meddelandet (SNI Outer). En okrypterad SNI Outer bÀr icke-integritetsdata sÄsom TLS-versionen och en lista över anvÀnda chiffer, samt ett vanligt domÀnnamn som inte överlappar det faktiska namnet pÄ den begÀrda domÀnen. Till exempel, för alla Cloudflare-klienter, anger den okrypterade SNI Outer den gemensamma vÀrden "cloudflare-ech.com", men det faktiska namnet pÄ den begÀrda vÀrden sÀnds i den krypterade SNI Inner och Àr inte tillgÀnglig för analys.
ECH anvÀnder ocksÄ ett annat distributionsschema för krypteringsnycklar: information om publika nyckelr överförs i HTTPSSVC DNS-poster snarare Àn TXT-poster. Autentiserad end-to-end-kryptering baserad pÄ HPKE-mekanismen (Hybrid Public Key Encryption) anvÀnds för att erhÄlla och kryptera nyckeln. ECH stöder ocksÄ sÀker nyckelÄteröverföring frÄn servern, vilket kan anvÀndas vid nyckelrotation. server och för att lösa problem med att hÀmta förÄldrade nycklar frÄn DNS-cachen.
KĂ€lla: opennet.ru
