
CRLSet
Ein CRLSet ist eine kompakte Liste gesperrter Sicherheitszertifikate, die Google an den Chrome-Browser verteilt — ohne dass Chrome dafür eine separate Anfrage an einen externen Server stellen muss. Es ist Googles Antwort auf das Problem, abgelaufene oder missbrauchte Zertifikate schnell und zuverlässig zu blockieren.
Wenn du eine Website mit « https:// » aufrufst, prüft dein Browser ein Sicherheitszertifikat — eine Art digitaler Ausweis, der bestätigt, dass die Seite echt ist. Solche Zertifikate können ungültig werden, zum Beispiel weil ein Unternehmen gehackt wurde oder das Zertifikat falsch ausgestellt war. Dann muss der Browser das schnell wissen. Ein CRLSet ist eine von Google regelmäßig aktualisierte Liste genau dieser gesperrten Zertifikate. Chrome lädt sie automatisch im Hintergrund herunter und kann damit sofort entscheiden, ob einem Zertifikat noch zu vertrauen ist.
Das Problem, das CRLSet löst
Früher gab es für diesen Zweck sogenannte CRLs — Certificate Revocation Lists. Das Prinzip ist dasselbe: eine Liste gesperrter Zertifikate. Der Unterschied liegt in der Zustellung. Bei einer klassischen CRL schickt der Browser bei jedem HTTPS-Seitenaufruf eine Anfrage an einen externen Server, um zu prüfen, ob das Zertifikat noch gilt. Das kostet Zeit und funktioniert gar nicht, wenn der Prüfserver gerade nicht erreichbar ist.
Browser haben dieses Problem lange dadurch gelöst, dass sie bei einem nicht erreichbaren Prüfserver einfach nichts tun — das Zertifikat also stillschweigend als gültig behandeln. Das klingt pragmatisch, ist aber ein Sicherheitsproblem: Ein Angreifer könnte gezielt dafür sorgen, dass der Prüfserver unerreichbar ist, um ein gesperrtes Zertifikat weiterzunutzen. Dieses Muster nennt man « Soft Fail ».
Wie Google die Liste verteilt
Google umgeht das Problem, indem Chrome die Liste nicht erst im Moment des Seitenbesuchs abruft, sondern sie regelmäßig vorab herunterlädt — als kompaktes Datenpaket, das direkt in den Browser integriert wird. Besucht Chrome dann eine HTTPS-Seite, schaut er nur lokal in diese Liste. Es gibt keine externe Anfrage mehr, keinen Prüfserver, der ausfallen könnte.
Die Updates kommen über denselben Mechanismus, über den Chrome auch andere Komponenten aktualisiert — unabhängig vom vollständigen Browser-Update. Google kann also binnen Stunden auf einen neu bekannt gewordenen Zertifikatsmissbrauch reagieren, ohne dass Nutzer ihren Browser neu starten oder eine neue Version installieren müssen. Wie schnell das in der Praxis sein kann, zeigte sich 2011: Als die Zertifizierungsstelle DigiNotar kompromittiert wurde und Hunderte falsche Zertifikate ausgestellt hatte, konnte Google die betroffenen Zertifikate innerhalb weniger Tage für alle Chrome-Nutzer blockieren.
Ein wichtiger Unterschied zur klassischen CRL: Das CRLSet ist bewusst klein gehalten. Es enthält nicht jedes je gesperrte Zertifikat, sondern konzentriert sich auf sicherheitskritische Fälle — vor allem auf Stammzertifikate (sogenannte Root- und Intermediate-Zertifikate), deren Kompromittierung viele Websites auf einmal betreffen würde. Für weniger kritische Fälle verlässt Chrome sich auf andere Mechanismen.
CRLSet in der Praxis und in den News
Für die meisten Nutzer bleibt das CRLSet unsichtbar. Es arbeitet still im Hintergrund, und wenn Chrome eine Seite aufgrund eines gesperrten Zertifikats blockiert, erscheint schlicht eine Fehlerseite. Dennoch taucht der Begriff immer wieder in Sicherheitsberichten auf — etwa wenn Forscher öffentlich diskutieren, wie schnell Browser auf neue Zertifikatsprobleme reagieren.
Andere Browser haben ähnliche Systeme entwickelt. Firefox nutzt zum Beispiel OneCRL, das nach demselben Grundprinzip funktioniert: eine zentral gepflegte, lokal gespeicherte Sperrliste statt einzelner Serveranfragen. Der wesentliche Unterschied liegt in der Verwaltung: Firefoxs OneCRL wird von Mozilla gepflegt, Googles CRLSet von Google selbst — was jeweils bedeutet, dass das jeweilige Unternehmen entscheidet, welche Zertifikate als gefährlich eingestuft werden.
Für alle, die sich mit Web-Sicherheit beschäftigen — sei es im Informatik-Unterricht, beim Lesen von Tech-News oder beim Entwickeln eigener Webseiten — ist das CRLSet ein gutes Beispiel dafür, wie Sicherheit und Geschwindigkeit in modernen Systemen gegeneinander abgewogen werden: Eine vollständige Liste wäre sicherer, aber zu groß; eine Serveranfrage wäre vollständiger, aber zu langsam und zu anfällig.