A Mozilla vállalat a Firefox éjszakai buildjeiben a visszavont tanúsítványok meghatározásának új mechanizmusának teszteléséről — . A CRLite hatékony tanúsítvány-visszahívás ellenőrzést tesz lehetővé a felhasználó rendszerén tárolt adatbázis alapján. A Mozilla által fejlesztett CRLite megvalósítás MPL 2.0 szabad licenc alatt áll. Az adatbázis generálásához és a szerveroldali komponensekhez használt kód Go nyelven íródott. A Firefoxhoz hozzáadott kliensoldali részek az adatbázisból származó adatok olvasására Rust nyelven készültek.
A tanúsítványok eddig használt ellenőrzése külső szolgáltatások bevonásával, az (Online Certificate Status Protocol) garantált hálózati elérhetőséget igényel, és jelentős késleltetést okoz a kérdés feldolgozásában (átlagosan 350 ms), emellett adatvédelmi problémái is vannak (az OCSP-kérdésekre válaszoló szerverek információkat kapnak a konkrét tanúsítványokról, amelyek alapján megítélhető, hogy a felhasználó mely weboldalakat látogatja). Létezik lehetőség helyi ellenőrzésre is a (Tanúsítvány-visszahívási lista) alapján, azonban ennek a módszernek a hátránya a letöltött adatok rendkívül nagy mérete – jelenleg a visszavont tanúsítványok adatbázisa körülbelül 300 MB-ot foglal el, és folyamatosan növekszik.
A Firefoxban a 2015 óta használt központosított fekete lista kombinálva a szolgáltatással a potenciális rosszindulatú aktivitás meghatározására. Az OneCRL, akárcsak a Chrome-ban, egy köztes elem, amely aggregálja a hitelesítő hatóságok CRL-listáit, és egy központosított OCSP-szolgáltatást biztosít a visszavont tanúsítványok ellenőrzésére, lehetővé téve ezzel, hogy közvetlenül ne kelljen kérdéseket küldeni a hitelesítő hatóságoknak. A tanúsítványok online ellenőrzési szolgáltatásának megbízhatóságának javítása érdekében végzett nagy erőfeszítések ellenére a telemetriai adatok azt mutatják, hogy az OCSP-kérdések több mint 7%-a időtúllépéssel zárul (néhány évvel ezelőtt ez az arány 15% volt).
Alapértelmezés szerint, ha a böngésző nem tudja ellenőrizni az OCSP-n keresztül, akkor a tanúsítványt érvényesnek tekinti. A szolgáltatás elérhetetlen lehet hálózati problémák és belső korlátozások miatt, vagy a támadók blokkolhatják – egy MITM-támadás során elegendő az OCSP-ellenőrzés megkerüléséhez, ha egyszerűen blokkolják a hitelesítési szolgáltatás elérését. Részben a hasonló támadások megelőzésére valósították meg a technikát , amely lehetővé teszi az OCSP-val kapcsolatos hiba vagy az OCSP elérhetetlenségének mint tanúsítványproblémának való értelmezését, azonban ez az opció opcionális, és speciális tanúsítványt igényel.
A CRLite lehetővé teszi, hogy a visszavont tanúsítványokról teljes információt könnyen frissíthető struktúrában tároljunk, amely mindössze 1 MB méretű, így lehetővé teszi a teljes CRL tárolását a kliens oldalán.
A böngésző naponta szinkronizálhatja a visszavont tanúsítványok adatait, és ez az adatbázis minden körülmények között elérhető lesz.
A CRLite összegyűjti az információkat , a kiadott és visszavont tanúsítványok nyilvános naplójából, valamint az interneten végzett tanúsítvány-ellenőrzés eredményeiből (különféle CA CRL-listáit gyűjtjük össze, és összegyűjtjük az összes ismert tanúsítványra vonatkozó információt). Az adatokat kaszkádos , valószínűségi struktúrával csomagolják, amely lehetővé teszi a hiányzó elem téves azonosítását, de kizárja a meglévő elem kihagyását (azaz bizonyos valószínűséggel előfordulhat, hogy egy érvényes tanúsítványra tévesen reagál, de a visszavont tanúsítványok garantáltan azonosításra kerülnek).
A hamis riasztások elkerülése érdekében a CRLite-ban további korrekciós szintet vezettek be. A struktúra generálása után az összes forrástartalmat átvizsgálják, és meghatározzák a felmerült hamis riasztásokat. A tesztelés eredményei alapján egy kiegészítő struktúra jön létre, amely kaszkádosan rákerül az elsőre, és korrigálja a felmerült hamis riasztásokat. Ez a folyamat addig ismétlődik, amíg a felügyeleti ellenőrzés során a hamis riasztások teljesen ki nem záródnak. Általában a teljes adatkör lefedéséhez elegendő 7-10 réteg létrehozása. Mivel az adatbázis (DB) állapota a periódikus szinkronizálás miatt kissé elmarad a CRL aktuális állapotától, az új tanúsítványok ellenőrzését, amelyeket az utolsó DB CRLite frissítése után állítottak ki, OCSP protokollal végzik, beleértve a technikát. (a hitelesítő hatóság által aláírt OCSP válasz a webhelyet kiszolgáló szerver által kerül átadásra a TLS kapcsolat egyeztetésekor).
A Bloom-szűrők segítségével a WebPKI decemberi adatszeletét, amely 100 millió aktív tanúsítványt és 750 ezer visszavont tanúsítványt ölel fel, 1,3 MB méretű struktúrába sikerült csomagolni. A struktúra generálásának folyamata rendkívül erőforrásigényes, de a Mozilla szerverén hajtják végre, és a felhasználónak már kész frissítést adnak át. Például a generáláshoz használt alapadatok bináris formában körülbelül 16 GB memóriát igényelnek Redis adatbázisban tárolva, a tanúsítványok összes sorozatszámának hexadecimális formátumban végzett dumpja pedig körülbelül 6,7 GB terjedelmű. A visszavont és aktív tanúsítványok aggregálásának folyamata körülbelül 40 percet vesz igénybe, míg a Bloom-szűrő alapú csomagolt struktúra generálása további 20 percet igényel.
Jelenleg a Mozilla naponta négyszer frissíti a CRLite DB-t (nem minden frissítést szolgáltatnak az ügyfeleknek). A delta-frissítések generálása jelenleg nem valósult meg - a bsdiff4 használata, amely a kiadások delta-frissítéseinek létrehozásához szükséges, nem biztosít elegendő hatékonyságot a CRLite számára, és a frissítések indokolatlanul nagyok. E hiányosságok kiküszöbölésére tervezik a tárolási struktúra formátumának átdolgozását a felesleges újjáépítés és a rétegek eltávolítása érdekében.
A CRLite a Firefox böngészőben passzív módban működik, és párhuzamosan használatos az OCSP-vel a működés helyességéről gyűjtött statisztikákhoz. A CRLite-t a fő ellenőrzési módra is át lehet állítani, ehhez az about:config menüben a security.pki.crlite_mode = 2 paramétert kell beállítani.
Forrás: opennet.ru
