Das Unternehmen Mozilla Über den Beginn der Testphase in den nächtlichen Builds von Firefox für den neuen Mechanismus zur Bestimmung zurückgezogener Zertifikate — . CRLite ermöglicht eine effektive Überprüfung des Widerrufs von Zertifikaten anhand einer auf dem System des Nutzers gespeicherten Datenbank. Die in Mozilla entwickelte Implementierung von CRLite steht unter der freien Lizenz MPL 2.0. Der Code zur Generierung der DB und die Serverkomponenten sind in und Go geschrieben. Die in Firefox hinzugefügten Client-Komponenten zum Auslesen von Daten aus der DB sind in der Sprache Rust geschrieben.
Die bis heute angewandte Überprüfung von Zertifikaten durch externe Dienste auf Basis des Protokolls (Online Certificate Status Protocol) erfordert einen garantierten Netzwerkzugang, führt zu spürbaren Verzögerungen bei der Verarbeitung der Anfrage (im Durchschnitt 350 ms) und hat Probleme mit der Gewährleistung der Vertraulichkeit (die auf Anfragen antwortenden OCSP-Server erhalten Informationen über spezifische Zertifikate, aus denen man schließen kann, welche Webseiten der Nutzer aufruft). Es gibt auch die Möglichkeit der lokalen Überprüfung anhand von Listen (Certificate Revocation List), aber der Nachteil dieser Methode ist die sehr große Größe der heruntergeladenen Daten — derzeit umfasst die Datenbank für zurückgezogene Zertifikate etwa 300 MB und ihr Wachstum dauert an.
Um kompromittierte und von Zertifizierungsstellen widerrufene Zertifikate zu blockieren, wird seit 2015 in Firefox eine zentralisierte schwarze Liste verwendet in Kombination mit dem Aufruf des Dienstes zur Erkennung möglicher schädlicher Aktivitäten. OneCRL, wie auch in Chrome, fungiert als verbindendes Element, das CRL-Listen von Zertifizierungsstellen aggregiert und einen einheitlichen, zentralisierten OCSP-Dienst zur Überprüfung zurückgezogener Zertifikate bereitstellt, wodurch es möglich ist, keine Anfragen direkt an die Zertifizierungsstellen zu senden. Trotz großer Anstrengungen zur Verbesserung der Zuverlässigkeit des Online-Überprüfungsdienstes zeigen Telemetriedaten, dass mehr als 7 % der OCSP-Anfragen mit einem Timeout enden (vor einigen Jahren betrug dieser Wert 15 %).
Standardmäßig gilt ein Zertifikat als gültig, wenn die Prüfung über OCSP nicht möglich ist. Der Dienst kann aus Netzwerkproblemen oder internen Netzwerkbeschränkungen nicht verfügbar sein oder von Angreifern blockiert werden – zur Umgehung der OCSP-Prüfung während eines MITM-Angriffs reicht es aus, den Zugang zum Prüfungsdienst zu blockieren. Teilweise ist eine Technik implementiert, um solche Angriffe zu verhindern. , die es ermöglicht, einen OCSP-Fehler oder die Nichterreichbarkeit von OCSP als Problem mit dem Zertifikat zu werten, wobei diese Möglichkeit optional ist und eine spezielle Zertifikatsausstellung erfordert.
CRLite ermöglicht es, umfassende Informationen über alle widerrufenen Zertifikate in einer leicht aktualisierbaren Struktur von nur 1 MB zu bündeln, was die vollständige Speicherung der CRL-Datenbank auf der Client-Seite ermöglicht.
Der Browser wird täglich seine Kopie der Daten über widerrufene Zertifikate synchronisieren können, und diese Datenbank wird unter allen Bedingungen verfügbar sein.
CRLite vereint Informationen aus , einem öffentlichen Protokoll aller ausgestellten und widerrufenen Zertifikate, sowie den Ergebnissen der Zertifikatsscans im Internet (verschiedene CRL-Listen von Zertifizierungsstellen werden gesammelt und Informationen über alle bekannten Zertifikate aggregiert). Die Daten werden mit Hilfe von kaskadierenden , probabilistischen Strukturen verpackt, die ein falsches Vermissen eines nicht vorhandenen Elements erlauben, jedoch das Übersehen eines vorhandenen Elements ausschließen (d. h. mit gewisser Wahrscheinlichkeit kann es ein falsch positives Ergebnis für ein gültiges Zertifikat geben, jedoch werden widerrufene Zertifikate garantiert erkannt).
Um falsche Alarme in CRLite auszuschließen, wurden zusätzliche Korrekturfilterebenen eingeführt. Nach der Erstellung der Struktur erfolgt die Durchsicht aller ursprünglichen Datensätze und die Bestimmung der entstandenen falschen Alarme. Basierend auf den Ergebnissen dieser Überprüfung wird eine zusätzliche Struktur erstellt, die kaskadenartig auf die erste aufgebracht wird und die entstandenen falschen Alarme korrigiert. Der Vorgang wird so lange wiederholt, bis bei der Kontrollüberprüfung falsche Alarme vollständig ausgeschlossen sind. Normalerweise genügt die Erstellung von 7-10 Schichten, um alle Daten vollständig abzudecken. Da der Zustand der Datenbank aufgrund der periodischen Synchronisation etwas hinter dem aktuellen Zustand der CRL zurückbleibt, wird die Überprüfung neuer Zertifikate, die nach dem letzten Update der CRLite-Datenbank ausgestellt wurden, mithilfe des OCSP-Protokolls durchgeführt, einschließlich der Technologie. (die von der Zertifizierungsstelle signierte OCSP-Antwort wird vom Server der gehosteten Seite während des TLS-Handshakes übermittelt).
Durch die Verwendung von Bloom-Filtern konnte der Dezember-Datenausschnitt aus der 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 Generierung der Struktur ist relativ ressourcenintensiv, wird jedoch auf dem Server von Mozilla durchgeführt und dem Benutzer wird bereits ein fertiges Update bereitgestellt. Die bei der Generierung verwendeten Ursprungsdaten benötigen beispielsweise in binärer Form etwa 16 GB Speicherplatz in der Redis-Datenbank, während die dumpierten Seriennummern aller Zertifikate in hexadezimaler Form etwa 6,7 GB einnehmen. Der Prozess der Aggregation aller widerrufenen und aktiven Zertifikate dauert etwa 40 Minuten, und der Prozess der Generierung der kompaktierten Struktur basierend auf dem Bloom-Filter benötigt weitere 20 Minuten.
Derzeit wird die CRLite-Datenbank in Mozilla viermal täglich aktualisiert (nicht alle Updates werden an die Kunden ausgeliefert). Die Generierung von Delta-Updates ist noch nicht implemented — die Anwendung von bsdiff4, das zur Erstellung von Delta-Updates für Releases verwendet wird, bietet keine ausreichende Effizienz für CRLite und die Updates werden unverhältnismäßig groß. Um dieses Manko zu beheben, soll das Format der Speicherstruktur überarbeitet werden, um unnötige Umstrukturierungen und das Entfernen von Schichten auszuschließen.
CRLite funktioniert derzeit im passiven Modus in Firefox und wird parallel zu OCSP genutzt, um Statistiken über die Funktionalität zu sammeln. CRLite kann in den Modus der Hauptüberprüfung versetzt werden, indem der Parameter security.pki.crlite_mode = 2 in about:config gesetzt wird.
Quelle: opennet.ru
