Prüfung des Status von Serverzertifikaten
Serverzertifikate müssen dann für ungültig erklärt werden, wenn der Server respektive der geheime private Schlüssel kompromittiert wurde. Mittels des Online Certificate Status Protocol (OCSP) können Clients den Status eines Serverzertifikats durch Anfrage bei einem so genannten OCSP-Responder abfragen. Dieser OCSP-Responder wird in der Regel von dem*der Aussteller*in des Zertifikats betrieben, der*die vom Server-Betreiber über den Widerruf informiert wird. Meldet der OCSP-Responder, dass das Zertifikat zurückgezogen (revoked) wurde, dann warnt i.d.R. der Clients den*die Nutzer*in und bricht den Verbindungsaufbau ab.
Doch wenn der Client keine OCSP-Antwort bekommt, fährt er in den meisten Standardeinstellungen mit dem Verbindungsaufbau fort (soft-fail strategy). Das könnten Angreifende für sich ausnutzen und die OCSP-Kommunikation (OCSP-Anfragen oder -Antworten) einfach blockieren (bzw. bis zum timeout verzögern) oder durch gefälschte „tryLater“-Antworten die Zertifikatsprüfung aushebeln.
Als Abhilfe wird das OCSP-stapling-Verfahren (RFC 6066) in Verbindung mit der sog. OCSP-must-staple-Anweisung (RFC 7633) empfohlen: Bei diesem Verfahren holt sich der Server regelmäßig eine digital signierte OCSP-Antwort vom OCSP-Responder und liefert diese einem Client beim Verbindungsaufbau zusammen mit dem Zertifikat aus (stapled). Dadurch entfällt die Notwendigkeit, dass der Client die OCSP-Antwort selbst beim OCSP-Responder anfordert. Gleichzeitig signalisiert der Server dem Client über eine TLS-Zertifikats-Erweiterung, dass er die Verbindung ablehnen sollte, falls er ihm keine zum Zertifikat passende positive OCSP-Antwort mitliefert (hard-fail strategy, must-staple).
In der Theorie ist dieses Zusammenspiel zwischen Server und Client deutlich robuster gegen den oben skizzierten Angriff. Der bekannte Test für Webserver Qualsys SSL Labs wird die Bestnote A+ nur vergeben, wenn der Webserver OCSP-stapling anbietet und das TLS-Zertifikat die Erweiterung mitbringt.
Moderne Webserver (Nginx, Apache, IIS) unterstützen OCSP-stapling (Anleitung für Apache und nginx), die DFN-PKI und Let's Encrypt-PKI wiederum unterstützen das notwendige "status_request"-Feature im Certificate Signing Requests (CSR) für die OCSP-must-staple-Anweisung.
Der Wermutstropfen: Während OCSP-stapling für sich genommen von modernen Clients unterstützt wird, ist OCSP-must-staple (also die Anwendung der sichereren hard-fail-Strategie auf Basis des Zertifikatseintrages) bisher nur in Firefox implementiert.
Fazit
Auch wenn OCSP-must-staple noch nicht bei allen Browser-Herstellenden angekommen ist, gilt schon allein das zugrunde liegende OCSP-stapling als datenschutzfreundliche und netzwerk-effizientere Alternative zum herkömmlichen OCSP - und das unterstützen alle modernen Browser. Die BSI Richtlinie TR-03116-4 (Kryptografische Vorgaben für Kommunikationsverfahren in Anwendungen, Stand 2019) empfiehlt ebenfalls OCSP-Stapling.