OCSP-Datenschutz: Der Responder sieht ein Zertifikat, nicht Ihre URL

Eine Statusprüfung stellt eine Frage zu einem Zertifikat, und die Antwort reist über ihre eigene Verbindung. Sie enthält nicht den Pfad der Seite, der zur Prüfung geführt hat. Datenschutzdebatten behandeln den Austausch oft als Verlaufsstrom des Browsens, was überschätzt, was die Anfrage trägt, und unterschätzt, was der Responder beobachten kann. Lesen Sie die Anfrage, bevor Sie entscheiden, was sie verrät.

Die Anfrage identifiziert ein Zertifikat

Die OCSP-Zertifikatskennung wird aus einer Hashfunktion, zwei Hashes des Ausstellers und der Seriennummer des Zielzertifikats gebildet, wie in RFC 6960 festgelegt. Jedes Feld verweist auf ein Zertifikat, nicht auf eine URL oder eine HTTP-Anfrage.

Der Pfad der Seite, die Abfragezeichenfolge und etwaige Formularinhalte fehlen in der Standardkennung. Die Behauptung, der Responder erhalte die genaue URL, benötigt Belege von woanders als aus der Zertifikatsprüfung. Die Anfrage nennt weiterhin ein Zertifikat und einen Zeitpunkt, und der Responder kann wissen, welcher Dienst es vorlegt.

Was fehlt, ist die Seite, nicht der gesamte Kontext. Eine Zertifikatsprüfung plus ein bekannter Dienst plus eine wiederkehrende Quelle können mehr aussagen als jedes davon für sich.

Was der Responder tatsächlich beobachten kann

Der Responder sieht die Verbindung, die ihn erreicht: Quelladresse, Zeitpunkt und alle Transportmetadaten, die seine Bereitstellung aufzeichnet. Folgt die Statusanfrage dem VPN, kann diese Quelle der VPN-Ausgang statt des Zugangsnetzes des Nutzers sein. Gehen Sie nicht davon aus, dass die Statusanfrage denselben Weg nimmt wie die Seitenanfrage, nur weil beide zu einer Browsersitzung gehören.

Prüfen Sie das unterstützte Routing und Verifikationsverhalten des Clients, statt es aus einer einzelnen Aufzeichnung abzuleiten. Ein geteilter Tunnel kann die beiden Anfragen in unterschiedliche Richtungen schicken.

Eine angeheftete Antwort ist das andere gängige Muster. Die TLS-Erweiterung status_request aus RFC 6066 erlaubt es einem Server, eine OCSP-Antwort an seinen eigenen Handshake anzuhängen, sodass der Client prüft, was ihm gegeben wurde, statt für diese Verbindung selbst den Status abzurufen. Dieser Wechsel verändert den Beobachter. Die Serverseite ruft ab, und die eigene Adresse des Clients erreicht den Responder für diese Verbindung nie.

Der Status kann im Handshake angeheftet ankommen

Nichts davon garantiert, dass ein Client nie eine weitere Validierungsanfrage stellt. Kettenaufbau, Statusrichtlinie und unterstützte Mechanismen unterscheiden sich je nach Implementierung.

Eine Zertifikatsanzeige in einem Browser beschreibt nicht jedes Betriebssystem und jeden VPN-Client. Derselbe Netzwerkausschnitt kann unter verschiedenen Verifikationseinstellungen Unterschiedliches bedeuten.

Zwischenspeichern bricht die Annahme einer Seite pro Abfrage

Zwischenspeichern entkoppelt Seitenaufrufe von Abfragen. Der Browser kann eine Antwort eine Zeit lang wiederverwenden, sodass ein Seitenaufruf nicht eine Netzwerkanfrage bedeutet.

Der umgekehrte Fehler ist genauso verbreitet. Eine zwischengespeicherte Antwort sagt nichts darüber, wann die nächste Aktualisierung erfolgt, und der Aktualisierungsplan kann nichts mit der geöffneten Seite zu tun haben. Nutzen Sie die aktuelle Dokumentation des Clients und die geltende Verifikationsrichtlinie, bevor Sie einen Ausschnitt OCSP zuordnen.

Eine gültige Statusantwort muss die Echtheits- und Frischeregeln des Prüfers erfüllen, und ein HTTP 200 ist nicht dasselbe wie ein guter Status. Eine Zeitüberschreitung ist kein Widerruf. Diese Ergebnisse führen zu unterschiedlichem Clientverhalten und sollten nicht zu einem Fehler zusammengefasst werden.

Datenschutzoptionen, die die Validierung intakt lassen

Wo die Abfrage selbst sensibel ist, besprechen Sie unterstützte Zustellungs- und Zwischenspeicheroptionen mit dem Systemeigentümer. Lösen Sie es nicht, indem Sie die Widerrufsprüfung oder die Kettenvalidierung abschalten.

Eine leisere Spur ist keine sicherere Verbindung. Lassen Sie Peer-Identität, Kettenvalidierung und die beabsichtigte Widerrufsrichtlinie intakt, und ändern Sie den Zustellungsweg nur über eine Option, die die Bereitstellung unterstützt. Halten Sie fest, welche Option gewählt wurde und wer sie verantwortet.

Wenn eine Abfrage unerwartet auftaucht, benennen Sie Empfänger, Route und Zertifikatsvorgang getrennt. Ein Aussteller-Download, eine Statusabfrage und die Seitenanfrage sind drei Ereignisse. Sie als eines zu behandeln macht die Datenschutzprüfung ungenau und verbirgt, welche Partei tatsächlich etwas erfahren hat. Beginnen Sie bei den Protokollfeldern und arbeiten Sie sich nach außen zum Netzwerkpfad vor.