Die Uhr auf dem Nachweis: Was OCSP Stapling verteilte und was es nicht übertrug

Zusammenfassung

• Der Server konnte eine signierte OCSP-Antwort zusammen mit seinem Zertifikat übermitteln. Er wurde damit zum Überbringer, nicht zur zuständigen Instanz für die Statusaussage; der Client musste weiterhin selbst prüfen.
• Wiederverwendung verringerte zusätzliche Abfragen, machte aber Aktualisierung und Zeitprüfung entscheidend. Eine Funktionszusage im Zertifikat konnte fehlende Nachweise bewertbar machen und zugleich die Zertifikatsumstellung an deren Verfügbarkeit binden.

Drei Zeiten auf einer Antwort

Ein Statusnachweis kann korrekt signiert sein und trotzdem nicht mehr genügen. Das Problem ist keine fehlerhafte Unterschrift, sondern die Zeit zwischen dem bekannten Zustand und seiner späteren Verwendung.

OCSP unterscheidet dafür mehrere Zeitangaben. thisUpdate bezeichnet den Zeitpunkt, zu dem der mitgeteilte Status als richtig bekannt war. producedAt hält die Signierung fest. nextUpdate sagt, bis wann neuere Informationen verfügbar sein werden. Wer eine frühere Beobachtung später signiert, hat damit nicht automatisch eine neue Beobachtung vorgenommen.

Diese Trennung erklärt eine Grenze von OCSP Stapling. Ein Server konnte einen vorbereiteten Nachweis bei vielen Verbindungen mitgeben. Der Client musste den Statusdienst dann nicht für jede entsprechend abgedeckte Prüfung selbst kontaktieren. Doch die ersparte Verbindung machte aus dem Nachweis keinen fortlaufend aktualisierten Blick in die Gegenwart.

Wiederverwendung war Teil des Entwurfs

Der leichte OCSP-Profilentwurf RFC 5019 beschrieb im September 2007 Vorproduktion, Verteilung und Zwischenspeicherung als Mittel zur Skalierung. Sein Zeitmodell verlangte nextUpdate und eine hinreichend genaue Uhr beim Prüfer. Im grundlegenden OCSP kann dieses Feld dagegen fehlen; die Profilanforderung ist nicht mit einer universellen Vorgabe gleichzusetzen.

Auch ein HTTP-Cachehinweis konnte die Signatur nicht nachträglich erweitern. Solche ungeschützten Transportangaben liefern Hinweise zur Speicherung, keine eigenständige Berechtigung, einen Status länger zu akzeptieren, als die Prüfung der signierten Antwort erlaubt.

Für den Betrieb entstand ein zeitlich begrenzter Puffer. War der Statusdienst vorübergehend unerreichbar, konnte eine noch akzeptable gespeicherte Antwort weiterhin nützlich sein. Sobald sie die Anforderungen des Clients nicht mehr erfüllte, war diese Reserve verbraucht. Ein neu veröffentlichter Widerruf änderte die zuvor verteilten positiven Antworten nicht rückwirkend.

Die Effizienz beruhte also nicht auf dem Verschwinden der Abhängigkeit, sondern auf einer kontrollierten zeitlichen Entkopplung.

Der Server durfte liefern, aber nicht selbst entscheiden

Damit dieser Puffer überhaupt vertrauenswürdig sein konnte, musste die Antwort unabhängig von ihrem Überbringer prüfbar sein. Ein Server, dessen Zertifikat gerade geprüft wurde, durfte die Belege liefern. Er durfte deshalb noch lange nicht festlegen, was sie aussagten.

RFC 6960 verlangt die Prüfung des Zertifikatsbezugs, der Signatur, der Identität und Befugnis des Signierenden sowie der Aktualität. Die ausstellende CA, ein ausdrücklich vertrauter Responder oder ein entsprechend autorisierter delegierter Responder können die vorgesehenen Rollen erfüllen. Der gewöhnliche TLS-Schlüssel eines Webservers verleiht keine OCSP-Signaturbefugnis.

Der Status good ist zudem enger, als sein Name nahelegt. Er beweist nicht zwangsläufig, dass das Zertifikat überhaupt ausgestellt wurde. Er bestätigt weder die Harmlosigkeit einer Website noch ersetzt er die übrige Zertifikatsprüfung. Ein günstiger Status ist ein bestimmter Nachweis, keine allgemeine Vertrauensentscheidung.

Erzeuger, Überbringer und Prüfer bleiben somit getrennt. Der Entwurf kann einen Beteiligten mit Eigeninteresse als Transportweg nutzen, gerade weil die Berechtigung zur Aussage nicht aus dem Transportweg abgeleitet wird.

Die Abkürzung stand schon 2003 im Standard

RFC 3546 erlaubte im Juni 2003 die Anforderung von Statusinformationen durch status_request. Der Server konnte eine OCSP-Antwort nach dem Zertifikat senden. Begrenzte Netzressourcen, die Übertragung von Widerrufslisten und zusätzliche Hin- und Rückwege gehörten zur Begründung.

Die im Januar 2011 veröffentlichte RFC 6066 beschrieb die Erweiterung im späteren TLS-Rahmen. Dort transportierte eine separate CertificateStatus-Nachricht die vollständig codierte Antwort. Das Jahr 2011 markiert somit nicht die Erfindung des Prinzips.

Wenn der mitgelieferte Status genügte, entfiel eine zusätzliche Verbindung des Besuchers zu einem Dritten. Der Datenschutzgewinn war konkret: Diese Statusabfrage musste nicht stattfinden. Eine allgemeine Anonymitätsgarantie folgte daraus ebenso wenig wie die dauerhafte Unabhängigkeit vom Responder. Der Server brauchte weiterhin neue Antworten.

Was das Ausbleiben verriet

Die frühe Erweiterung war freiwillig. Aus einer Anfrage des Clients folgte keine sichere Lieferung. Fehlender Status konnte fehlende Unterstützung bedeuten, aber auch bewusstes Zurückhalten.

Die Sicherheitsbetrachtung von RFC 6066 nennt ausdrücklich einen Angreifer mit kompromittiertem Schlüssel, der sich als nicht unterstützender Server ausgibt. Ein Client, der OCSP-Validierung benötigt, sollte den Responder selbst kontaktieren oder abbrechen. Eine empfangene, aber unzureichende Antwort war ein anderer Fall und erforderte den Abbruch der Aushandlung. Schweigen war keine Widerrufsmeldung.

RFC 7633 führte im Oktober 2015 eine Möglichkeit ein, die Erwartung im Zertifikat festzuhalten. Die X.509-Erweiterung TLS Feature konnte status_request angeben. Darauf beruht das gewöhnlich Must-Staple genannte Verfahren: Ein unterstützender Client konnte die tatsächliche Lieferung mit einer authentifizierten Zusage vergleichen.

Das war keine Verpflichtung aller Clients, jede Funktion zu implementieren oder überall identisch zu scheitern. Die Spezifikation sah auch alternative Validierungsmöglichkeiten vor. Für den Server hatte die Zusage dennoch Folgen. Ein neues Zertifikat sollte nicht eingesetzt werden, bevor der benötigte Statusnachweis verfügbar war. Andernfalls konnte ein rechtmäßig ausgestelltes Zertifikat an einer unerfüllten Erwartung scheitern.

Neuer Behälter, unveränderte Zuständigkeiten

Mit RFC 8446 von 2018 kam der Status in TLS 1.3 in eine Erweiterung des zugehörigen CertificateEntry. Die ältere separate Handshake-Nachricht war dafür nicht mehr das Gefäß. Die Befugnis zum Signieren wanderte trotzdem nicht zum Server.

OCSP Stapling machte somit einen überprüfbaren Beleg beweglich, ohne die zugehörige Autorität mitzuverkaufen. Die Rechnung ging nur auf, wenn Aktualisierung, Zuordnung und Prüfung weiter funktionierten. Die RFCs belegen diesen Entwurf; sie sind keine Erhebung über die heutige Unterstützung aller Browser und CAs.

Quellen

RFC 3546, RFC 6066, RFC 6960, RFC 5019, RFC 7633 und RFC 8446. Die wirtschaftliche Zuordnung der Arbeit ist eine Analyse der Anforderungen, keine Behauptung gemessener Verbreitung.