Kompromittierte SSL-Zertifikate: PSW GROUP begrüßt Apples und Mozillas Forderung nach vollständigen Sperrlisten

(Auszug aus der Pressemitteilung)

Fulda, 13.02.2023 – Künftig soll es wieder möglich sein, kompromittierte SSL-Zertifikate einfach zu sperren. Die IT-Sicherheitsexperten der PSW GROUP (www.psw-group.de) begrüßen einen entsprechenden Vorstoß von Apple und Mozilla: „Es ist kaum zu glauben, aber es gibt in der IT-Sicherheit tatsächlich ein Thema, das fast in Vergessenheit geraten ist – nämlich die Verwaltung von SSL-Zertifikaten. Bislang gibt es keine allgemeingültige Methode, nach der ein kompromittiertes SSL-Zertifikat gesperrt und damit aus dem Verkehr gezogen werden kann. Die Forderung von Apple und Mozilla nach Zertifikatsperrlisten ist deshalb längst überfällig und baut einen gewissen Druck auf, sich der Problematik anzunehmen“, so Geschäftsführerin Patrycja Schrenk.

Ein SSL-Zertifikat gilt als kompromittiert und muss beim Herausgeber, der Certification Authority (CA) bzw. Zertifizierungsstelle, gesperrt werden, wenn der private, geheime Schlüssel gestohlen oder veröffentlicht wurde. In der Vergangenheit gab es zwei Mechanismen, welche SSL-Zertifikate als gesperrt kennzeichneten, falls diese kompromittiert wurden: Zunächst die Abfrage über Certificate Revocation Lists. Da die von den Zertifizierungsstellen geführten Certificate Revocation Lists (CRL) schnell mehrere Mbytes groß werden können und erst vom Client heruntergeladen werden müssen, erwies sich diese Methode als ungeeignet für eine schnelle Überprüfung, ob sich darin ein gesperrtes Zertifikat befindet oder nicht.

Die Alternative zu den CRLs sollte das Online Certificate Status Protocol, kurz OCSP, sein. Mit dessen Hilfe lässt sich durch Anfrage bei einem so genannten OCSP-Responder oder OCSP-Server feststellen, ob ein SSL-Zertifikat bereits gesperrt wurde oder noch gültig ist. „Ob ein SSL-Zertifikat gesperrt ist, erfährt ein Browser demnach, wenn er bei einem OCSP-Responder eine erfolgreiche Anfrage durchführt. Lautet die Antwort “good” ist das SSL-Zertifikat nicht gesperrt, lautet sie “revoked” ist das SSL-Zertifikat gesperrt“, erklärt Schrenk. Das Verfahren kann jedoch zu deutlich längeren Ladezeiten bei Website-Aufrufen führen, weil für die OCSP-Antwort häufig das Abrufen der verteilten Seitenbestandteile über mehrere Server erforderlich ist.

Die IT-Sicherheitsexpertin verweist auf zwei weitere Probleme: „Der OCSP-Responder bekommt jede Website-Anfrage mit und erhält damit auch die gesamte Suchhistorie einer Person, mit all ihrer vertraulichen Daten, serviert. Aus datenschutzrechtlicher Sicht ist das ein No-Go. Obendrein können Angreifende mittels Man-in-the-Middle Attacke eine verschlüsselte Verbindung umleiten und übernehmen, dazu ein gesperrtes SSL-Zertifikat verwenden und so die OCSP-Abfragen blockieren.“ In einem solchen Fall würde der Browser oder Client keine Antwort vom Server bekommen und davon ausgehen, dass das SSL-Zertifikat in Ordnung sei. 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.

„Diese drei Gründe genügten den Browser-Herstellern, OCSP nicht zur Pflicht zu machen. Eigene Zertifikatsperrlisten für Notfälle und kürzere Laufzeiten der Zertifikate sollten das damit entstehende Risiko begrenzen. Alles in allem ist das aber natürlich eine sehr unbefriedigende Situation. So ist es nicht überraschend und nur nachvollziehbar, dass Apple und Mozilla nun von Zertifizierungsstellen fordern, vollständige Sperrlisten bereitzustellen, welche sie dann in die Truststores ihrer Browser aufnehmen wollen“, erklärt Patrycja Schrenk. Anders als bei den früheren CRLSs fungieren die Truststores als Zwischenstation: Sie sollen die Zertifikatsperrlisten zentral einsammeln und dann als eine kompakte Liste an ihre Browser weitergeben. Offenbar erlaubt diese Zwischenstation ausreichend viele Optimierungen, sodass die Skalierungs- und Performance-Probleme der herkömmlichen CRLs gelöst werden können.

Patrycja Schrenk

„Während mit Let’s Encrypt die größte CA von Mozillas und Apples Vorschlag begeistert zu sein scheint und bereits die neuen CRLs in Betrieb genommen hat, hat ausgerechnet Google mit seinem marktbeherrschenden Chrome-Browser sich meines Wissens nach noch nicht zu den neuen CRLs zu Wort gemeldet. Dabei ist Google recht aktiv, wenn es um Richtlinien für digitale Zertifikate geht und keine Antwort bedeutet nicht gleich eine Ablehnung“, so Patrycja Schrenk. Tatsächlich hat Google 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 wurde jedoch deutlich, dass das bei Massensperrungen nicht zuverlässig funktioniert.