Mozilla implementeert CRLite om te controleren op problematische TLS-certificaten

Mozilla-bedrijf kondigde het over de start van het testen in nachtelijke builds van Firefox van een nieuw mechanisme voor het detecteren van ingetrokken certificaten - CRLite. Met CRLite kunt u een effectieve controle van de intrekking van certificaten organiseren aan de hand van een database die op het systeem van de gebruiker wordt gehost. Mozilla's CRLite-implementatie gepubliceerd onder de gratis MPL 2.0-licentie. De code voor het genereren van de database- en servercomponenten is geschreven Python en gaan. Clientonderdelen toegevoegd aan Firefox voor het lezen van gegevens uit de database bereid in Roest-taal.

Certificaatverificatie met behulp van externe diensten op basis van het protocol dat nog steeds wordt gebruikt OCSP (Online Certificate Status Protocol) vereist gegarandeerde netwerktoegang, leidt tot een aanzienlijke vertraging in de verwerking van verzoeken (gemiddeld 350 ms) en heeft problemen met het waarborgen van de vertrouwelijkheid (OCSP-servers die op verzoeken reageren, ontvangen informatie over specifieke certificaten, die kan worden gebruikt om te beoordelen of wat sites die de gebruiker opent). Ook bestaat de mogelijkheid tot lokale controle aan de hand van lijsten CRL (Certificate Revocation List), maar het nadeel van deze methode is de zeer grote omvang van de gedownloade gegevens - momenteel beslaat de database met ingetrokken certificaten ongeveer 300 MB en de groei gaat door.

Om certificaten te blokkeren die zijn gecompromitteerd en ingetrokken door certificeringsinstanties, gebruikt Firefox sinds 2015 een gecentraliseerde zwarte lijst EénCRL in combinatie met een call-to-service Google Safe Browsing om mogelijke kwaadaardige activiteiten te identificeren. OneCRL, zoals CRL-sets in Chrome fungeert als tussenliggende link die CRL-lijsten van certificeringsinstanties samenvoegt en biedt één gecentraliseerde OCSP-service voor het controleren van ingetrokken certificaten, waardoor het mogelijk wordt om verzoeken niet rechtstreeks naar certificeringsinstanties te sturen. Ondanks veel werk om de betrouwbaarheid van de online certificaatverificatiedienst te verbeteren, blijkt uit telemetriegegevens dat ruim 7% van de OCSP-verzoeken een time-out krijgt (een paar jaar geleden was dit nog 15%).

Als verificatie via OCSP niet mogelijk is, beschouwt de browser het certificaat standaard als geldig. De service is mogelijk niet beschikbaar vanwege netwerkproblemen en beperkingen op interne netwerken, of wordt geblokkeerd door aanvallers. Om de OCSP-controle tijdens een MITM-aanval te omzeilen, blokkeert u eenvoudigweg de toegang tot de controleservice. Mede om dergelijke aanvallen te voorkomen is een techniek geïmplementeerd Moet nieten, waarmee u een OCSP-toegangsfout of OCSP-onbeschikbaarheid als een probleem met het certificaat kunt behandelen, maar deze functie is optioneel en vereist een speciale registratie van het certificaat.

Met CRLite kunt u volledige informatie over alle ingetrokken certificaten consolideren in een eenvoudig te updaten structuur van slechts 1 MB groot, waardoor het mogelijk is om een ​​volledige CRL-database aan de clientzijde op te slaan.
De browser zal zijn kopie van de gegevens over ingetrokken certificaten dagelijks kunnen synchroniseren en deze database zal onder alle omstandigheden beschikbaar zijn.

CRLite combineert informatie uit Certificaattransparantie, een openbaar logboek van alle uitgegeven en ingetrokken certificaten, en de resultaten van het scannen van certificaten op internet (er worden verschillende CRL-lijsten van certificeringsinstanties verzameld en informatie over alle bekende certificaten samengevoegd). Gegevens worden verpakt met behulp van cascadering Bloom-filters, een probabilistische structuur die een valse detectie van een ontbrekend element mogelijk maakt, maar het weglaten van een bestaand element uitsluit (dat wil zeggen dat met een bepaalde waarschijnlijkheid een vals positief resultaat voor een correct certificaat mogelijk is, maar ingetrokken certificaten worden gegarandeerd geïdentificeerd).

Om valse positieven te elimineren heeft CRLite extra corrigerende filterniveaus geïntroduceerd. Na het genereren van de structuur worden alle bronrecords doorzocht en worden eventuele false positives geïdentificeerd. Op basis van de resultaten van deze controle wordt een extra structuur gecreëerd, die op de eerste wordt gecascadeerd en de resulterende valse positieven corrigeert. De bewerking wordt herhaald totdat valse positieven tijdens de controlecontrole volledig zijn geëlimineerd. Normaal gesproken is het maken van zeven tot tien lagen voldoende om alle gegevens volledig te bedekken. Omdat de status van de database als gevolg van periodieke synchronisatie enigszins achterblijft bij de huidige status van de CRL, wordt de controle van nieuwe certificaten uitgegeven na de laatste update van de CRLite-database uitgevoerd met behulp van het OCSP-protocol, inclusief het gebruik van het OCSP-nieten (een OCSP-antwoord gecertificeerd door een certificeringsinstantie wordt verzonden door de server die de site bedient tijdens het onderhandelen over een TLS-verbinding).

Mozilla implementeert CRLite om te controleren op problematische TLS-certificaten

Met behulp van Bloom-filters kon het informatiefragment van december van WebPKI, dat 100 miljoen actieve certificaten en 750 ingetrokken certificaten omvatte, worden verpakt in een structuur van 1.3 MB groot. Het structuurgeneratieproces is behoorlijk arbeidsintensief, maar het wordt uitgevoerd op de Mozilla-server en de gebruiker krijgt een kant-en-klare update. In binaire vorm vereisen de brongegevens die tijdens het genereren worden gebruikt bijvoorbeeld ongeveer 16 GB geheugen wanneer ze worden opgeslagen in het Redis DBMS, en in hexadecimale vorm neemt een dump van alle certificaatserienummers ongeveer 6.7 GB in beslag. Het proces van het verzamelen van alle ingetrokken en actieve certificaten duurt ongeveer 40 minuten, en het proces van het genereren van een pakketstructuur op basis van het Bloom-filter duurt nog eens 20 minuten.

Mozilla zorgt er momenteel voor dat de CRLite-database vier keer per dag wordt bijgewerkt (niet alle updates worden bij klanten afgeleverd). Het genereren van delta-updates is nog niet geïmplementeerd - het gebruik van bsdiff4, dat wordt gebruikt om delta-updates voor releases te maken, biedt niet voldoende efficiëntie voor CRLite en de updates zijn onredelijk groot. Om dit nadeel te elimineren, is het de bedoeling om het formaat van de opslagstructuur te herwerken om onnodig opnieuw opbouwen en verwijderen van lagen te elimineren.

CRLite werkt momenteel in Firefox in passieve modus en wordt parallel met OCSP gebruikt om statistieken over de juiste werking te verzamelen. CRLite kan worden overgeschakeld naar de hoofdscanmodus; hiervoor moet u de parameter security.pki.crlite_mode = 2 instellen in about:config.

Mozilla implementeert CRLite om te controleren op problematische TLS-certificaten

Bron: opennet.ru

Voeg een reactie