Die Mozilla Corporation zum Start von Tests in den nächtlichen Builds von Firefox des neuen Mechanismus zur Identifizierung zurückgerufener Zertifikate — . CRLite ermöglicht eine effiziente Überprüfung von Zertifikaten anhand einer Datenbank, die lokal auf dem System des Benutzers gehostet wird. Die von Mozilla entwickelte CRLite-Implementierung steht unter der freien Lizenz MPL 2.0. Der Code zur Generierung der Datenbank und die Serverkomponenten sind in und Go geschrieben. Die in Firefox hinzugefügten Clientteile zum Auslesen der Daten aus der Datenbank sind in Rust geschrieben.
Die bisher verwendete Überprüfung von Zertifikaten mit externen Diensten auf der Basis des Protokolls (Online Certificate Status Protocol) erfordert garantierten Netzwerkzugang, führt zu spürbaren Verzögerungen bei der Bearbeitung von Anfragen (im Durchschnitt 350 ms) und hat Datenschutzprobleme (die Server, die auf Anfragen antworten, erhalten Informationen über spezifische Zertifikate, anhand derer man Rückschlüsse darauf ziehen kann, welche Websites der Benutzer besucht). Es besteht auch die Möglichkeit einer lokalen Überprüfung anhand von Listen. (Certificate Revocation List), jedoch ist ein Nachteil dieser Methode die sehr große Größe der heruntergeladenen Daten – derzeit beträgt die Datenbank der widerrufenen Zertifikate etwa 300 MB und wächst weiter.
Um kompromittierte und von Zertifizierungsstellen widerrufene Zertifikate zu blockieren, wird seit 2015 in Firefox eine zentralisierte schwarze Liste verwendet. in Kombination mit dem Zugriff auf den Dienst um potenzielle bösartige Aktivitäten zu erkennen. OneCRL, ähnlich wie in Chrome, fungiert als eine Zwischeninstanz, die CRL-Listen von Zertifizierungsstellen aggregiert und einen einheitlichen zentralisierten OCSP-Dienst zur Überprüfung widerrufener Zertifikate bereitstellt, was es ermöglicht, keine Anfragen direkt an die Zertifizierungsstellen zu senden. Trotz der umfangreichen Bemühungen zur Verbesserung der Zuverlässigkeit des Online-Zertifikatsprüfungsdienstes zeigen Telemetriedaten, dass mehr als 7 % der OCSP-Anfragen mit einem Timeout enden (vor einigen Jahren lag dieser Wert bei 15 %).
Standardmäßig betrachtet der Browser ein Zertifikat als gültig, wenn eine Überprüfung über OCSP nicht möglich ist. Der Dienst kann aufgrund von Netzwerkproblemen und Einschränkungen in internen Netzwerken nicht verfügbar sein oder von Angreifern blockiert werden – um eine OCSP-Überprüfung während eines MITM-Angriffs zu umgehen, reicht es aus, den Zugang zum Überprüfungsdienst zu blockieren. Teilweise zur Vorbeugung solcher Angriffe wurde eine Technik umgesetzt, , die es ermöglicht, einen Fehler bei der Anfrage über OCSP oder die Unzugänglichkeit von OCSP als Problem mit dem Zertifikat zu interpretieren, aber diese Möglichkeit ist optional und erfordert eine spezielle Zertifikatsausstellung.
CRLite ermöglicht es, vollständige Informationen über alle widerrufenen Zertifikate in einer leicht aktualisierbaren Struktur mit einer Größe von nur 1 MB zusammenzufassen, was die Speicherung einer vollständigen CRL-Datenbank auf der Client-Seite ermöglicht.
Der Browser kann täglich seine Kopie der Daten über widerrufene Zertifikate synchronisieren, und diese Datenbank wird unter allen Bedingungen verfügbar sein.
CRLite kombiniert Informationen aus , öffentlicher Protokoll aller ausgegebenen und zurückgezogenen Zertifikate sowie Ergebnisse der Zertifikatsscans im Internet (verschiedene CRL-Listen von Zertifizierungsstellen werden gesammelt und Informationen zu allen bekannten Zertifikaten aggregiert). Die Daten werden mit Hilfe von kaskadierten , probabilistischer Struktur verpackt, die eine falsche Bestimmung eines fehlenden Elements zulässt, aber das Übersehen eines vorhandenen Elements ausschließt (d.h. mit einer bestimmten Wahrscheinlichkeit kann es zu einem Fehlalarm bei einem gültigen Zertifikat kommen, aber zurückgezogene Zertifikate werden garantiert identifiziert).
Um Fehlalarme in CRLite zu vermeiden, wurden zusätzliche Anpassungsfilterebenen eingeführt. Nach der Erstellung der Struktur erfolgt eine Durchsicht aller ursprünglichen Datensätze, um aufgetretene Fehlalarme zu identifizieren. Nach dieser Überprüfung wird eine zusätzliche Struktur erstellt, die kaskadierend auf die erste aufgebracht wird, um die aufgetretenen Fehlalarme zu korrigieren. Dieser Vorgang wird solange wiederholt, bis bei der Kontrollüberprüfung keine Fehlalarme mehr vorhanden sind. Üblicherweise sind 7-10 Schichten notwendig, um alle Daten vollständig abzudecken. Da der Zustand der Datenbank aufgrund periodischer Synchronisation etwas hinter dem aktuellen Zustand der CRL zurückbleibt, erfolgt die Überprüfung neuer Zertifikate, die nach dem letzten Update der CRLite-Datenbank ausgestellt wurden, mittels des OCSP-Protokolls, unter Verwendung der Technik (die durch das Zertifizierungsstelle bestätigte OCSP-Antwort wird vom betreibenden Webserver während der Aushandlung der TLS-Verbindung übermittelt).
Mit Hilfe von Bloom-Filtern konnte der Dezember-Datenextrakt aus WebPKI, der 100 Millionen aktive Zertifikate und 750.000 widerrufene Zertifikate umfasst, in einer Struktur mit einer Größe von 1,3 MB verpackt werden. Der Prozess der Strukturgenerierung ist recht ressourcenintensiv, wird jedoch auf dem Server von Mozilla ausgeführt, sodass den Nutzern bereits das fertige Update bereitgestellt wird. Zum Beispiel benötigen die verwendeten Ausgangsdaten in binärer Form bei der Generierung etwa 16 GB Speicherplatz in der Redis-Datenbank, während der hexadezimale Dump aller Seriennummern der Zertifikate ungefähr 6,7 GB groß ist. Der Prozess der Aggregierung aller widerrufenen und aktiven Zertifikate dauert etwa 40 Minuten, und die Generierung der verpackten Struktur auf Basis des Bloom-Filters benötigt weitere 20 Minuten.
Derzeit wird die CRLite-Datenbank in Mozilla viermal täglich aktualisiert (nicht alle Aktualisierungen werden an die Kunden weitergeleitet). Die Generierung von Delta-Updates ist bisher nicht realisiert – die Anwendung von bsdiff4, das zur Erstellung von Delta-Updates für Versionen verwendet wird, bietet nicht die gewünschte Effizienz für CRLite, sodass die Updates unverhältnismäßig groß werden. Um dieses Problem zu beheben, ist eine Überarbeitung des Speicherformatlayouts geplant, um unnötige Rekonstruktionen und Schichtenentfernungen zu vermeiden.
CRLite arbeitet derzeit passiv in Firefox und wird parallel zu OCSP verwendet, um Statistiken über die korrekte Funktionsweise zu sammeln. CRLite kann in den Hauptprüfmodus versetzt werden, indem in about:config der Parameter security.pki.crlite_mode auf 2 gesetzt wird.
Quelle: opennet.ru
