Mozilla Company om starten på testing i nattlige versjoner av Firefox, en ny mekanisme for å oppdage tilbakekalte sertifikater - . CRLite lar deg organisere effektiv kontroll av tilbakekalling av sertifikater mot en database som ligger på brukerens system. Mozillas CRLite-implementering under den gratis MPL 2.0-lisensen. Koden for å generere databasen og serverkomponentene er skrevet inn og gå. Klientdeler lagt til Firefox for å lese data fra databasen på rustspråk.
Sertifikatverifisering ved bruk av eksterne tjenester basert på protokollen som fortsatt brukes (Online Certificate Status Protocol) krever garantert nettverkstilgang, fører til en betydelig forsinkelse i forespørselsbehandlingen (350 ms i gjennomsnitt) og har problemer med å sikre konfidensialitet (OCSP-servere som svarer på forespørsler mottar informasjon om spesifikke sertifikater, som kan brukes til å bedømme om hva nettsteder brukeren åpner). Det er også mulighet for lokal kontroll mot lister (Certificate Revocation List), men ulempen med denne metoden er den svært store størrelsen på de nedlastede dataene - for øyeblikket opptar databasen med tilbakekalte sertifikater omtrent 300 MB, og veksten fortsetter.
For å blokkere sertifikater som har blitt kompromittert og tilbakekalt av sertifiseringsmyndighetene, har Firefox brukt en sentralisert svarteliste siden 2015 i kombinasjon med en oppfordring til tjeneste for å identifisere mulig ondsinnet aktivitet. OneCRL, liksom i Chrome, fungerer som en mellomkobling som samler CRL-lister fra sertifiseringsmyndigheter og gir én enkelt sentralisert OCSP-tjeneste for å sjekke tilbakekalte sertifikater, noe som gjør det mulig å ikke sende forespørsler direkte til sertifiseringsmyndighetene. Til tross for mye arbeid med å forbedre påliteligheten til den elektroniske sertifikatverifiseringstjenesten, viser telemetridata at mer enn 7 % av OCSP-forespørslene tidsavbrutt (for noen år siden var dette tallet 15 %).
Som standard, hvis det er umulig å verifisere via OCSP, anser nettleseren sertifikatet som gyldig. Tjenesten kan være utilgjengelig på grunn av nettverksproblemer og restriksjoner på interne nettverk, eller blokkert av angripere – for å omgå OCSP-sjekken under et MITM-angrep, blokkerer du bare tilgangen til sjekktjenesten. Delvis for å forhindre slike angrep, har en teknikk blitt implementert , som lar deg behandle en OCSP-tilgangsfeil eller OCSP-tilgjengelighet som et problem med sertifikatet, men denne funksjonen er valgfri og krever spesiell registrering av sertifikatet.
CRLite lar deg konsolidere fullstendig informasjon om alle tilbakekalte sertifikater til en enkelt oppdatert struktur, kun 1 MB stor, som gjør det mulig å lagre en komplett CRL-database på klientsiden.
Nettleseren vil kunne synkronisere sin kopi av dataene om tilbakekalte sertifikater daglig, og denne databasen vil være tilgjengelig under alle forhold.
CRLite kombinerer informasjon fra , en offentlig logg over alle utstedte og tilbakekalte sertifikater, og resultatene av skanning av sertifikater på Internett (ulike CRL-lister over sertifiseringsinstanser samles inn og informasjon om alle kjente sertifikater er samlet). Data pakkes ved hjelp av cascading , en sannsynlighetsstruktur som tillater en falsk påvisning av et manglende element, men utelukker utelatelse av et eksisterende element (dvs. med en viss sannsynlighet er en falsk positiv for et korrekt sertifikat mulig, men tilbakekalte sertifikater er garantert identifisert).
For å eliminere falske positiver har CRLite introdusert ytterligere korrigerende filternivåer. Etter generering av strukturen søkes alle kildeposter og eventuelle falske positiver identifiseres. Basert på resultatene av denne kontrollen, opprettes en ekstra struktur, som kaskades over på den første og korrigerer de resulterende falske positivene. Operasjonen gjentas til falske positive under kontrollkontrollen er fullstendig eliminert. Vanligvis er det tilstrekkelig å lage 7-10 lag til å dekke alle data fullstendig. Siden tilstanden til databasen, på grunn av periodisk synkronisering, henger litt etter den nåværende tilstanden til CRL, blir sjekking av nye sertifikater utstedt etter siste oppdatering av CRLite-databasen utført ved hjelp av OCSP-protokollen, inkludert bruk av (et OCSP-svar sertifisert av en sertifiseringsinstans overføres av serveren som betjener nettstedet når det forhandles om en TLS-tilkobling).
Ved å bruke Bloom-filtre kunne desember-delen av informasjon fra WebPKI, som dekker 100 millioner aktive sertifikater og 750 tusen tilbakekalte sertifikater, pakkes inn i en struktur på 1.3 MB i størrelse. Strukturgenereringsprosessen er ganske ressurskrevende, men den utføres på Mozilla-serveren og brukeren får en ferdig oppdatering. For eksempel, i binær form, krever kildedataene som brukes under generering omtrent 16 GB minne når de er lagret i Redis DBMS, og i heksadesimal form tar en dump av alle sertifikatserienumre omtrent 6.7 GB. Prosessen med å samle alle tilbakekalte og aktive sertifikater tar omtrent 40 minutter, og prosessen med å generere en pakket struktur basert på Bloom-filteret tar ytterligere 20 minutter.
Mozilla sørger for tiden for at CRLite-databasen oppdateres fire ganger om dagen (ikke alle oppdateringer leveres til klienter). Generering av deltaoppdateringer er ennå ikke implementert - bruken av bsdiff4, brukt til å lage deltaoppdateringer for utgivelser, gir ikke tilstrekkelig effektivitet for CRLite og oppdateringene er urimelig store. For å eliminere denne ulempen er det planlagt å omarbeide formatet til lagringsstrukturen for å eliminere unødvendig gjenoppbygging og sletting av lag.
CRLite fungerer for tiden i Firefox i passiv modus og brukes parallelt med OCSP for å samle statistikk om riktig operasjon. CRLite kan byttes til hovedskanningsmodus; for å gjøre dette må du sette parameteren security.pki.crlite_mode = 2 i about:config.
Kilde: opennet.ru