Företaget Mozilla om början av testning i nattleveranser av Firefox av den nya mekanismen för att identifiera Ă„terkallade certifikat â . CRLite möjliggör effektiv kontroll av certifikatĂ„terkallande via en databas som placeras pĂ„ anvĂ€ndarens system. Den implementation av CRLite som utvecklas av Mozilla Ă€r licensierad under den fria licensen MPL 2.0. Koden för att generera databasen och serverkomponenter Ă€r skrivna i och Go. De klientdelar som lagts till i Firefox för att lĂ€sa data frĂ„n databasen Ă€r skrivna i Rust.
Den verifiering av certifikat som fortfarande tillĂ€mpas med hjĂ€lp av externa tjĂ€nster baserat pĂ„ protokollet (Online Certificate Status Protocol) krĂ€ver garanterad nĂ€tverksĂ„tkomst, vilket leder till en mĂ€rkbar fördröjning vid begĂ€ran (i genomsnitt 350 ms) och har problem med att sĂ€kerstĂ€lla sekretess (servrar som svarar pĂ„ begĂ€rningar fĂ„r information om specifika certifikat, vilket kan indikera vilka webbplatser anvĂ€ndaren besöker). Det finns ocksĂ„ en möjlighet för lokal kontroll via listor (Certificate Revocation List), men nackdelen med denna metod Ă€r den mycket stora storleken pĂ„ de nedladdade datamĂ€ngderna â för nĂ€rvarande upptar databasen med Ă„terkallade certifikat cirka 300 MB och dess tillvĂ€xt fortsĂ€tter.
För att blockera komprometterade och Äterkallade certifikat frÄn certifikatutfÀrdare har Firefox anvÀnt en centraliserad svart lista sedan 2015 i kombination med att anvÀnda tjÀnsten för att identifiera möjlig skadlig aktivitet. OneCRL, liksom i Chrome, fungerar som ett mellanled som aggregerar CRL-listor frÄn certifikatutfÀrdare och tillhandahÄller en centraliserad OCSP-tjÀnst för verifiering av Äterkallade certifikat, vilket gör det möjligt att inte skicka förfrÄgningar direkt till certifikatutfÀrdarna. Trots det stora arbetet för att öka tillförlitligheten hos tjÀnsten för onlineverifiering av certifikat visar telemetridata att mer Àn 7 % av OCSP-förfrÄgningarna slutar med tidsgrÀns (för nÄgra Är sedan var denna siffra 15 %).
Som standard, om det Ă€r omöjligt att utföra verifieringen via OCSP, anser webblĂ€saren att certifikatet Ă€r giltigt. TjĂ€nsten kan vara otillgĂ€nglig bĂ„de pĂ„ grund av nĂ€tverksproblem och begrĂ€nsningar i interna nĂ€tverk, samt blockerad av angripare â för att kringgĂ„ OCSP-verifieringen under en MITM-attack Ă€r det tillrĂ€ckligt att bara blockera Ă„tkomsten till verifieringstjĂ€nsten. Delvis för att förhindra sĂ„dana attacker har tekniken , vilket gör det möjligt att tolka ett fel vid begĂ€ran om OCSP eller otillgĂ€nglighet av OCSP som ett problem med certifikatet, men denna möjlighet Ă€r valfri och krĂ€ver en speciell utfĂ€rdande av certifikatet.
CRLite gör det möjligt att komprimera fullstÀndig information om alla Äterkallade certifikat i en lÀttuppdaterad struktur som endast Àr 1 MB stor, vilket gör det möjligt att lagra hela CRL-databasen pÄ klientsidan.
WebblÀsaren kommer att kunna synkronisera sin kopia av data om Äterkallade certifikat dagligen, och denna databas kommer att vara tillgÀnglig under alla omstÀndigheter.
CRLite sammanstÀller information frÄn , den offentliga loggen över alla utfÀrdade och Äterkallade certifikat, samt resultaten av certifikatgranskningar pÄ internet (olika CRL-listor frÄn certifikatutfÀrdare samlas in och information om alla kÀnda certifikat aggregeras). Uppgifterna paketeras med hjÀlp av kaskad , en probabilistisk struktur som medger falska positiva, men utesluter att ett befintligt element missas (det vill sÀga, med viss sannolikhet kan det hÀnda att ett korrekt certifikat felaktigt identifieras, men Äterkallade certifikat kommer garanterat att upptÀckas).
För att undvika falska larm i CRLite har ytterligare justeringsnivÄer införts. Efter genereringen av strukturen görs en genomgÄng av alla ursprungliga poster för att identifiera uppkomna falska larm. Baserat pÄ detta genomförs en ytterligare struktur som kaskadmÀssigt lÀggs ovanpÄ den första och justerar de uppkomna falska larmen. Denna operation upprepas tills alla falska larm Àr helt uteslutna vid kontrollgranskningen. Vanligtvis rÀcker det med att skapa 7-10 lager för att tÀcka alla data. Eftersom tillstÄndet i databasen pÄ grund av periodisk synkronisering Àr nÄgot fördröjd frÄn det aktuella tillstÄndet för CRL, kontrolleras nya certifikat som utfÀrdats efter den senaste uppdateringen av databasen CRLite med hjÀlp av OCSP-protokollet, inklusive att anvÀnda tekniken (evidens frÄn certifikatutfÀrdaren överförs av servern som betjÀnar webbplatsen vid förhandlingen av TLS-anslutningen).
Genom Bloom-filter kunde decemberbeskÀrningen av information frÄn WebPKI, som omfattar 100 miljoner aktiva certifikat och 750 000 Äterkallade certifikat, packas i en struktur som Àr 1,3 MB stor. Processen för att generera strukturen Àr ganska resurskrÀvande, men den utförs pÄ Mozillas server och levereras redan som en fÀrdig uppdatering till anvÀndaren. Till exempel, i binÀr form krÀver de ursprungliga data som anvÀnds vid genereringen cirka 16 GB minne nÀr de lagras i databasen Redis, medan dumpen av alla serienummer för certifikat i hexadecimalt format tar cirka 6,7 GB. Processen för aggregering av alla Äterkallade och aktiva certifikat tar cirka 40 minuter, och processen för att generera den packade strukturen baserad pÄ Bloom-filter krÀver ytterligare 20 minuter.
För nÀrvarande sÀkerstÀller Mozilla att databasen CRLite uppdateras fyra gÄnger om dagen (inte alla uppdateringar levereras till kunderna). Generering av delta-uppdateringar har Ànnu inte implementerats - anvÀndningen av bsdiff4, som anvÀnds för att skapa delta-uppdateringar av versioner, ger inte tillrÀcklig effektivitet för CRLite och uppdateringarna blir orÀttmÀtigt stora. För att ÄtgÀrda denna brist planeras en omarbetning av lagringsstrukturformatet för att undvika onödig omstrukturering och borttagning av lager.
CRLite fungerar för nÀrvarande i Firefox i passivt lÀge och anvÀnds parallellt med OCSP för att samla statistik om korrekt drift. CRLite kan vÀxlas till aktiv kontroll, för detta mÄste parameter security.pki.crlite_mode = 2 sÀttas i about:config.
KĂ€lla: opennet.ru
