SSL-Zertifikate: Das Revival der Zertifikatsperrlisten

Zukünftig soll es wieder möglich sein, kompromittierte SSL-Zertifikate einfach zu sperren. Apple und Mozilla preschen vor und die CA Let’s Encrypt ist mit dabei. In unserem Blogbeitrag beschäftigen wir uns heute mit dem Thema der Zertifikatsperrlisten und dem Vorschlag der beiden Browser-Hersteller. Außerdem werfen wir einen Blick auf die Vergangenheit, zeigen frühere Lösungsansätze auf und erklären, warum diese scheiterten.

Das Verwaltungsproblem bei SSL-Zertifikaten

Kaum zu glauben, aber es gibt auch in der IT-Sicherheit ein Thema, das fast in Vergessenheit geraten ist: Die Verwaltung von SSL-Zertifikaten. Denn bislang gibt es keine allgemeingültige Methode, nach der ein kompromittiertes SSL-Zertifikat gesperrt und damit aus dem Verkehr gezogen werden kann. Und so ist beispielsweise die Verkürzung der Laufzeit von SSL-Zertifikaten auch „nur“ die Bestrebung, damit wenigstens die Zeitspanne zu verkürzen, in der ein kompromittiertes Zertifikat im Umlauf ist, umso weniger Zeit für dessen Missbrauch und für etwaige Angriffe zu geben – dem damit einhergehenden Administrationsaufwand für Zertifizierungsstellen und Endnutzende inklusive.

Einen wirklich zufriedenstellenden Lösungsvorschlag für das Verwaltungsproblem bei SSL-Zertifikaten hatte jedoch niemand. Doch es gibt Neuigkeiten: Jetzt fordern Apple und Mozilla ein Revival der Zertifikatsperrlisten – und haben mit der weltgrößten Zertifizierungsstelle Let´s Encrypt auch ein Schwergewicht an Bord.

SSL-Zertifikat und Schlüssel ultrakurz zusammengefasst

Wir alle wissen, dass ein SSL-Zertifikat die Identität einer Webseite sicherstellt und den Datenverkehr verschlüsselt. Für die Verschlüsselung von Daten wird logischerweise ein Schlüssel benötigt – sowie ein weiterer für deren Entschlüsselung. Es wird also exakt ein Schlüsselpaar, bestehend aus einem öffentlichen und einem privaten Schlüssel, benötigt. Während der öffentliche Schlüssel eine Nachricht verschlüsselt, kann diese nur mit dem dazu passenden privaten Schlüssel wieder dechiffriert werden.

Wenn dieser private, geheime Schlüssel aber gestohlen und/ oder veröffentlicht wurde, damit das gesamte SSL-Zertifikat kompromittiert und muss beim Herausgeber, der Certification Authority (CA) bzw. Zertifizierungsstelle, gesperrt werden.

Rückblick: CRLs und OCSP

In der Vergangenheit gab es zwei Mechanismen, welche SSL-Zertifikate als gesperrt kennzeichneten, falls diese kompromittiert wurden: CRLs und OCSP.

Die Abfrage über Certificate Revocation Lists

Hat eine CA ein SSL-Zertifikat gesperrt, trägt sie dieses Zertifikat in eine Certificate Revocation List (CRL) ein. Das Problem dabei: Diese Listen können schnell mehrere Mbytes groß werden. Da diese Listen obendrein auch erst vom Client heruntergeladen werden müssen, sind sie für eine schnelle Überprüfung, ob sich ein gesperrtes Zertifikat darin befindet oder nicht, ungeeignet: Die Übermittlung an den Client und die eigentliche Überprüfung nehmen einfach viel zu viel Zeit in Anspruch. Hinzu kommt, dass Sperrlisten nicht immer ganz aktuell sind, da sie nur in bestimmten Intervallen erstellt werden.

Die Alternative: Online Certificate Status Protocols

Die Alternative zu CRLs sollte in der weiteren Entwicklung das Online Certificate Status Protocol sein. Mit Hilfe des Online Certificate Status Protocols, kurz OCSP, lässt sich durch Anfrage bei einem Server (ein so genannter OCSP-Responder) feststellen, ob ein SSL-Zertifikat gesperrt wurde bzw. noch gültig ist.

Ob ein SSL-Zertifikat gesperrt ist, erfährt ein Client oder Browser folglich, wenn er bei einem Server (OCSP-Responder – „OCSP-Antwortdienst“) eine erfolgreiche Anfrage durchführt: Lautet die Antwort „good“ ist das SSL-Zertifikat nicht gesperrt, lautet sie „revoked“ ist das SSL-Zertifikat gesperrt. Sollte die Antwort „unknown“ lauten, bedeutet dies, dass der Status nicht ermittelt werden konnte.

Kritik an OCSP

OCSP hat drei große Probleme: Zunächst wäre da die Sache mit dem Datenschutz. Der OCSP-Responder bekommt nämlich jede Website-Anfrage mit und erhält damit auch die gesamte Suchhistorie einer Person, mit all ihrer vertraulichen Daten, serviert.

Obendrein können Angreifende mittels einer Man-in-the-Middle Attacke eine verschlüsselte Verbindung umleiten und übernehmen, dazu ein gesperrtes SSL-Zertifikat verwenden und so die OCSP-Abfragen blockieren. Der Browser oder Client würde in diesem Fall keine Antwort vom Server bekommen und davon ausgehen, dass das SSL-Zertifikat in Ordnung sei. Experten sprechen in diesem Fall von einem „fail open“ oder einem „soft fail“. Hilfreicher wäre, bei ausbleibender Antwort eine Fehlermeldung zu erhalten, also ein „fail close“ oder „hard fail“.

Tatsächlich braucht es nicht einmal einen Angriff. Denn wenn ein Browser nach einer OCSP-Anfrage nicht innerhalb einer bestimmten Zeit eine Antwort erhält, ignoriert er diesen Zustand einfach und akzeptiert ein Zertifikat als gültig – auch wenn es zwischenzeitlich vielleicht gesperrt wurde. Versuche der Browser-Hersteller, daran etwas zu ändern, haben jedoch gezeigt, dass das nicht praktikabel wäre: Es gebe eine zu hohe Anzahl an Fehlalarmen, da die OCSP-Infrastruktur einfach nicht in der Qualität vorhanden ist, die für einen reibungslosen Ablauf nötig wäre.

Ein dritter Kritikpunkt: Die OCSP-Antwort erfordert häufig das Abrufen der verteilten Seitenbestandteile über mehrere Server, was zu deutlich längeren Ladezeiten bei Website-Aufrufen führen kann.

Apple und Mozilla fordern vollständige Sperrlisten

Diese drei Gründe genügten Browser-Herstellern, OCSP nicht zur Pflicht zu machen. Eigene Zertifikats-Sperrlisten für Notfälle und kürzere Laufzeiten der Zertifikate sollten das damit entstehende Risiko begrenzen. Alles in allem eine sehr unbefriedigende Situation.

Nun fordern Apple und Mozilla von CA-Zertifikaten vollständige Sperrlisten bereitzustellen. Diese Sperrlisten wollen die Hersteller in den Truststore ihrer Browser aufnehmen.

Neu dabei: Zwischenstation Truststore

Die Truststores sollen dabei wie eine Art Zwischenstation funktionieren: Sie sollen die Zertifikatsperrlisten zentral einsammeln und dann als eine kompakte Liste an ihre Browser weitergeben. Diese Zwischenstation erlaubt anscheinend ausreichend viele Optimierungen, dass man die Skalierungs- und Performance-Probleme der herkömmlichen CRLs gelöst werden können.

Und was ist mit Google?

Google hat sich schon lange vom Online Certificate Status Protocol verabschiedet und arbeitet bei seinem Browser Chrome mit so genannten CRLSets. Bei denen erhält der Browser über den Update-Mechanismus die wichtigsten Einträge der Sperrlisten. Durch den Heartbleed-Bug (OpenSSL) wurde jedoch offenbar, dass das bei Massensperrungen nicht zuverlässig funktioniert.

Während nun mit Let’s Encrypt zumindest die größte CA hellauf von Mozillas und Apples Vorschlag begeistert scheint und bereits die neuen CRLs in Betrieb genommen hat, hat ausgerechnet Google, der mit seinem Chrome-Browser immerhin eine marktbeherrschenden Position einnimmt, sich (noch) nicht zu den neuen CRLs zu Wort gemeldet. Dabei ist Google recht aktiv, wenn es um Richtlinien für digitale Zertifikate geht. Sollte der Konzern etwas gegen den Vorstoß von Apple und Mozilla haben, dürfte es den beiden schwer fallen, sich gegen den Platzhirsch durchzusetzen. Allerdings bedeutet keine Antwort nicht gleich eine Ablehnung – wir dürfen also gespannt bleiben.

Fazit zu Zertifikatsperrlisten

Es scheint nun bei diesem lange bekannten Verwaltungsproblem von SSL-Zertifikaten endlich etwas voranzugehen. Auch wenn derzeit noch unklar ist, ob die anderen Browserhersteller, geschweige denn die CAs selbst direkt mit einsteigen werden, dürfte das „Vorpreschen“ von Mozilla und Apple immerhin einen gewissen Druck aufbauen. Wir bleiben für Sie auf jeden Fall am Ball – und wer weiß, vielleicht können wie schon bald von einem ersten Test hier bei uns im Blog berichten. Haben Sie weitere Fragen zu SSL-Zertifikaten und Zertifikatsperrlisten? Nehmen Sie Kontakt zu uns auf! Wir beraten Sie gerne.