OCSP (Stapling): das Gute, das Schlechte und das Hässliche

Eine der wichtigsten Komponenten für ein sicheres Internet ist die verschlüsselte Kommunikation. Wer sich zum Beispiel zu seinem Online-Banking-Portal sicher verbinden möchte, braucht digitale Zertifikate. Diese werden oft von einer zentralen Stelle ausgestellt und sie sollen die Echtheit von Webseiten und anderen Diensten beweisen.

Nur gültige Zertifikate erlauben

Damit Zertifikate gültig sind, müssen sie bestimmten kryptografischen Anforderungen genügen. Außerdem besitzen Zertifikate immer einen festen Gültigkeitszeitraum: Sie sind nicht vor und nicht nach einem bestimmten Zeitpunkt gültig, wodurch Zertifikate vor Missbrauch geschützt werden.

In der Vergangenheit war es nicht unüblich, dass Zertifikate fünf oder mehr Jahre gültig waren, und natürlich wurden einige von ihnen in dieser Zeit von Hackern erbeutet. Die Hacker wiederum konnten sich bis zum Ablauf der Gültigkeit als der Dienst ausgeben, von dem sie das Zertifikat erbeutet hatten. Diesen Zeitraum also möglichst klein zu halten war mit ein Grund, weshalb führende Browserhersteller jüngst den Gültigkeits­­zeitraum auf 398 Tage begrenzt haben. Die Zertifizierungsstelle Let’s Encrypt geht sogar einen Schritt weiter und stellt Zertifikate mit maximal 90 Tagen Gültigkeit aus und empfiehlt diese sogar auf 60 Tage zu verkürzen.

Gültigkeit in Echtzeit überprüfen

Doch all die Zeiträume helfen nicht, wenn man doch bemerkt hat, dass mit dem Server etwas nicht stimmt und das Zertifikat möglicherweise einem Hacker in die Hände gefallen ist: Man muss es für ungültig erklären, und zwar möglichst schnell und sofort!

Neben relativ unhandlichen Zertifikatssperrlisten (Certificate Revocation Lists), die es im Internet zu keiner wirklich großen Verbreitung geschafft haben, existiert ein Verfahren, um die Gültigkeit von Zertifikaten bei einem Validierungsdienst abzufragen: das Online Certificate Status Protocol (OCSP).

Bei der Zertifikatsvalidierung über das Online Certificate Status Protocol stellt der Webbrowser beim Aufruf einer Webseite eine Anfrage (OCSP Request) an den Validierungsdienst der Zertifizierungsstelle, auch OCSP Responder genannt. Dieser Validierungsdienst liefert dem Webbrowser eine Antwort (OCSP Response) zurück. Sobald der Webbrowser die OCSP-Antwort erhalten hat, kann der Browser den Gültigkeitsstatus des Zertifikats in quasi Echtzeit überprüfen und das Zertifikat ablehnen, wenn es ungültig ist.

Wie so häufig hat der Mechanismus aber auch eine Kehrseite: es kann zu Datenschutzproblemen kommen, wenn unverschlüsselte OCSP-Anfragen abgehört werden. Das hat jüngst den Tech-Gigan­ten Apple zu einer Klar­stellung zur Daten­verwen­dung gezwungen, nachdem erneut kritisiert wurde, Betriebs­system­her­steller oder Internet­an­bieter könnten anhand der teilweise unver­schlüs­sel­ten Nutzungs­daten präzise Personen­profile erstellen. Gleiches gilt natürlich für den Validierungs­dienst, der sämtliche OCSP-Anfragen erhält.

Ebenso kann es bei Webseitenaufrufen zu längeren Ladezeiten kommen, da zusätzlich eine OCSP-Abfrage durchgeführt werden muss. Fällt der Validierungsdienst aus, kann die Verbindung unter Umständen überhaupt nicht hergestellt werden.

Die Abhängigkeit zu einem zweiten Dienst

Blockiert ein Angreifer die OCSP-Kommunikation und erhält der Browser in der Folge keine Antwort, wird die Webseite dennoch aufgerufen, ohne dabei eine Warnmeldung anzuzeigen. Dieses Verhalten bezeichnet man als sogenannten Soft Fail, der bei Ausfall des Validierungsdiensts nicht auch noch den Ausfall der Webseite nach sich ziehen soll.

Ein Verfahren nach dem Hard Fail Prinzip würde den Verbindungsaufbau blockieren und den Nutzer mit einer Warnmeldung über eine nicht erfolgreiche OCSP Validierung informieren. Allerdings wurde bisher nur im Mozilla Browser Firefox eine solche Warnmeldung integriert, die gleichzeitig auch den Verbindungsaufbau blockiert.

Alle Chromium-basierten Webbrowser (Chrome, Opera, Edge, Vivaldi et cetera) verzichten auf eine Warnmeldung und setzen auf die Verwendung von CRLSets, anstatt auf OCSP. Dadurch wollen sie die Benutzerfreundlichkeit wahren und Internetnutzer nicht mit einer Warnmeldung überfordern, die sie möglicherweise nicht verstehen würden. Bei CRLSets trifft man jedoch auf die typischen Probleme von Zertifikatssperrlisten: Größenbeschränkung, Unhandlichkeit und eine durch Versionen beschränkte Aktualität.

Über Umwege direkt zum Ziel: OCSP Stapling

Statt dass der Browser eine OCSP-Anfrage stellt, wird diese Aufgabe fortan vom Webserver übernommen. Der Webserver stellt selbst in regelmäßigen Abständen eine OCSP-Anfrage und übermittelt die Antwort im Verbindungsaufbau an den Browser. Die Antwort wird quasi an den Verbindungsaufbau angetackert, woher der Name OCSP Stapling rührt. Zunächst waren die Implementierungen der Webserver wie Nginx oder Apache für Stapling fehlerbehaftet, doch hat sich diese Situation wesentlich verbessert und es existiert mit mod_md in aktuellen Apache-Versionen eine einfache Möglichkeit OCSP-Stapling für alle ausgelieferten Zertifikate zu aktivieren.

Stapling löst das Datenschutzproblem, das durch die zusätzliche OCSP-Anfrage entsteht, da diese nun vom Webserver durchgeführt wird. Ebenso verbessert sich die Verbindungsgeschwindigkeit durch die eingesparte Abfrage und die Validierungsdienste werden entlastet. Durch die enthaltene Signatur der Zertifizierungsstelle und die Kurzlebigkeit der OCSP-Antwort kann ihr vertraut werden, obwohl sie nicht direkt vom OCSP Responder gesendet wird, sondern vom Webserver, an den ohnehin die eigentliche Webseiten-Anfrage gestellt wird.

Theoretisch ist es durch Stapling nicht mehr möglich die OCSP-Kommunikation zu blockieren. Ein Angreifer, der in Besitz eines gestohlenen Server-Zertifikats ist, müsste jedoch als böswilliger Dienstanbieter kein OCSP-Stapling anbieten. Der Browser würde die verschlüsselte Verbindung herstellen und anschließend versuchen eine OCSP-Anfrage durchzuführen. Diese könnte der Angreifer wiederum blockieren und mit einem bereits zurückgezogenen Zertifikat den Nutzer täuschen.

Um derartige Downgrade Angriffe zu verhindern, wurde eine Erweiterung für X.509-Zertifikate Must-Staple entworfen. Mittels dieser Erweiterung wird über das Zertifikat mitgeteilt, dass der Dienstbetreiber OCSP-Stapling anbieten muss.

Damit die Erweiterung Must-Staple zum Einsatz kommen kann, müssen Browserhersteller diese Zertifikatserweiterung umsetzen, was derzeit noch nicht von allen getan wird. Der Browser würde anhand des Zertifikats die Information Must-Staple erhalten und in der Folge eine OCSP-Antwort im Verbindungsaufbau erwarten. Erhält er diese Antwort nicht, muss er in einen Hard Fail-Zustand übergehen und die Verbindung versagen.

Durch diese Erweiterung kommen nur noch Verbindungen zustande, die eine gültige angeheftete OCSP -Information im Verbindungsaufbau mitliefern.
Es kann dennoch vorkommen, dass es einem Angreifer gelingt ein Zertifikat, den dazugehörigen Schlüssel und eine gültige OCSP-Antwort zu entwenden. Im ungünstigsten Fall würde zwar das Zertifikat vom eigentlichen Dienstanbieter zurückgezogen werden, aber der Angreifer könnte trotz Must-Staple während des üblichen Gültigkeitszeitraums der OCSP-Antwort von sieben Tagen das Zertifikat verwenden. Mit der nächsten Aktualisierung der OCSP-Antwort, spätestens nach sieben Tagen, würde das Zertifikat abschließend für ungültig erklärt werden.

Fazit: Mehr Gutes als Schlechtes, manchmal aber Hässlich

Um die Gültigkeit von Zertifikaten in Echtzeit zu überprüfen, wird das Online Certificate Status Protocol (OCSP) eingesetzt. Browser erhalten damit ein Werkzeug, um die Ungültigkeit von zurückgezogenen Zertifikaten festzustellen. Doch nur OCSP-Stapling in Verbindung mit der Zertifikatserweiterung Must-Staple behebt wesentliche Schwächen und sorgt für ein belastbares Verfahren. Auch wenn dieses nicht neu ist, mangelt es teilweise noch an der Unterstützung durch Webserver- oder Browser-Hersteller; diese hat sich jüngst wesentlich verbessert.

aramido wird in Kürze eine Lösung für OCSP-Stapling mit dem HAProxy in diesem Blog vorstellen.