Mozilla Company om begyndelsen af testningen i natversionerne af Firefox af den nye mekanisme til bestemmelse af tilbagekaldte certifikater — . CRLite muliggør effektiv kontrol af tilbagekaldte certifikater via en database, der hostes på brugerens system. Den version af CRLite, der udvikles i Mozilla, er under den åbne licens MPL 2.0. Koden til generering af databasen og serverkomponenterne er skrevet i og Go. De tilføjede klientdele i Firefox til at læse data fra databasen er skrevet i Rust.
Den hidtil anvendte kontrol af certifikater under involvering af eksterne tjenester baseret på protokollen (Online Certificate Status Protocol) kræver garanteret netværksadgang, medfører en mærkbar forsinkelse ved behandling af anmodningen (i gennemsnit 350 ms) og har problemer med at sikre fortroligheden (serverne, der svarer på anmodninger, om OCSP modtager oplysninger om specifikke certifikater, som kan indikere, hvilke websteder brugeren besøger). Der er også mulighed for lokal kontrol via listerne (Certificate Revocation List), men ulempe ved denne metode er den meget store størrelse af de downloadede data — i øjeblikket fylder databasen med tilbagekaldte certifikater omkring 300 MB, og dens størrelse vokser.
For at blokere kompromitterede og tilbagekaldte certifikater fra certifikatmyndighederne anvendes der i Firefox en centraliseret sortliste i kombination med adgang til tjenesten for at bestemme mulig skadelig aktivitet. OneCRL, ligesom i Chrome, fungerer som et mellemled, der aggregerer CRL-lister fra certifikatmyndighederne og giver en centraliseret OCSP-tjeneste til at kontrollere tilbagekaldte certifikater, hvilket gør det muligt ikke at sende anmodninger direkte til certifikatmyndighederne. På trods af det store arbejde med at forbedre pålideligheden af online-kontroltjenesten for certifikater viser telemetridata, at mere end 7% af OCSP-anmodningerne ender med timeout (for et par år siden var denne procentdel 15%).
Som standard betragter browseren et certifikat som korrekt, hvis OCSP-kontrol ikke kan udføres. Tjenesten kan være utilgængelig på grund af netværksproblemer og begrænsninger i interne netværk eller kan blive blokeret af angribere — for at omgå OCSP-kontrollen under en MITM-angreb er det nok at blokere adgangen til kontroltjenesten. Delvist for at forhindre sådanne angreb er teknikken implementeret , der gør det muligt at betragte en fejl ved OCSP-adgang eller utilgængelighed af OCSP som et problem med certifikatet, men denne mulighed er valgfri og kræver en særlig udformning af certifikatet.
CRLite gør det muligt at samle fuldstændige oplysninger om alle tilbagekaldte certifikater i en let opdaterbar struktur, der kun fylder 1 MB, hvilket giver mulighed for at gemme en komplet CRL-database på klientsiden.
Browseren vil kunne synkronisere sin kopi af dataene om tilbagekaldte certifikater dagligt, og denne database vil være tilgængelig under alle omstændigheder.
CRLite kombinerer oplysninger fra , den offentlige log over alle udstedte og tilbagekaldte certifikater, og resultaterne af scanning af certifikater på internettet (forskellige CRL-lister fra certifikatmyndigheder indsamles, og oplysninger om alle kendte certifikater aggregeres). Dataene pakkes ved hjælp af kaskade- , en probabilistisk struktur, der tillader falsk bestemmelse af et manglende element, men udelukker overspring af et eksisterende element (dvs. der er en vis sandsynlighed for falsk aktivering på et korrekt certifikat, men tilbagekaldte certifikater vil bestemt blive identificeret).
For excluding false positives in CRLite, additional correction levels have been introduced. After generating the structure, all source records are processed to identify the false positives that have arisen. Based on the results of this check, an additional structure is created, which is cascaded onto the first one and corrects any false positives. This operation is repeated until false positives are completely excluded during the control check. Usually, to fully cover all data, creating 7-10 layers is sufficient. Since the state of the database lags slightly behind the actual state of the CRL due to periodic synchronization, the check for new certificates issued after the last database update is performed using the OCSP protocol, including the use of the technique. (den verificerede OCSP-svar fra certifikatudstederen sendes af webstedets server under TLS-forbindelsesaftalen).
Using Bloom filters, the December snapshot of data from WebPKI, covering 100 million active certificates and 750,000 revoked certificates, was managed to be packed into a structure sized at 1.3 MB. The process of generating the structure is quite resource-intensive, but it is carried out on the Mozilla server, and the user receives a ready-made update. For example, in binary form, the original data used for generation requires about 16 GB of memory when stored in the Redis database, and the hexadecimal dump of all certificate serial numbers takes about 6.7 GB. The process of aggregating all revoked and active certificates takes about 40 minutes, while the process of generating the packed structure based on the Bloom filter requires another 20 minutes.
Currently, Mozilla ensures the CRLite database is updated four times a day (not all updates are delivered to clients). The generation of delta updates has not yet been implemented — the use of bsdiff4, which is used to create delta updates of releases, does not provide adequate efficiency for CRLite, and the updates become unjustifiably large. To address this drawback, it is planned to overhaul the storage structure format to eliminate unnecessary restructuring and layer removal.
CRLite fungerer i øjeblikket i Firefox i passiv tilstand og bruges parallelt med OCSP til at indsamle statistik om korrekt drift. CRLite kan omstilles til hovedkontroltilstand; for dette skal indstillingen security.pki.crlite_mode = 2 sættes i about:config.
Kilde: opennet.ru
