OCSP - Online Certificate Status Protocol

Zertifikate sind nur solang sicher, wie die Gültigkeit geprüft werden kann. Das gilt für den TÜV-Stempel, das Bioland-Zertifikat aber eben auch für SMIME und HTTP-Zertifikate. Dazu gibt es im Zertifikat selbst den Hinweis auf die ausstellende Zertifizierungsstelle, die zur Gültigkeit befragt werden kann. Neben der CRL gibt es auch noch OCSP,

OCSP statt CRL

Nun gibt es schon sei dem Anbeginn der PKI's die "Certificate Revocation List", über die jede PKI veröffentlichen kann. Allerdings muss dazu der Client die CRL der PKI herunterladen und die Hashwerte der Zertifikate darin suchen und vergleichen. Das Problem ist aber weniger der Client sondern dass die PKI ja jedem beliebigen Client die CRL bereitstellen muss. Die PKI muss neben einem öffentlichen Namen natürlich auch die entsprechenden Kapazitäten beim Webserver vorhalten. zudem hat eine CRL eine Gültigkeitsdauer, was zu zwei Problemen führt.

  • Neuer Download
    Wenn die CRL abgelaufen ist, muss ein Client beim nächsten Zugriff wieder die CRL von der PKI herunterladen.
  • Aktualität zu langsam
    Die meisten CRLs haben zudem eine Gültigkeitsdauer von 1-7 Tagen. Das kann sehr lange sein, wenn ein Zertifikat wirklich missbraucht wird und die PKI dieses schon zurückgezogen hat.

Das waren die ersten Überlegungen, warum OCSP entwickelt wurde.

So funktioniert OCSP

Es ist Aufgabe des Client die Gültigkeit eines Zertifikats zu überprüfen. Das erfolgt in mehreren Schritten

  1. Client-A startet eine eine TLS Verbindung zu Server-B
  2. Server B liefert Zertifikat mit Name, Ausstellende CA, Gültigkeitsdauer und natürlich CRL und OCSP Informationen
  3. Client-A prüft Zertifikat und fragt dazu natürlich OCSP die PKI-C
  4. PKI-C antwortet
  5. Client überträgt Daten zu Server-B

Ein Client ist nicht immer nur ein Browser und der Server ist nicht immer ein WebServer. Dieser Handshake bezieht sich auf alle zertifikatsgesicherten Verbindungen. Es kann neben HTTPS auch SMTPS, SSH, POP3S u.a. sein.

Es ist relativ einfach zu analysieren, ob ihr Client OCSP macht. Es ist einfach eine unverschlüsselte HTTPS-Anfrage, die durch eine in sich signierte Antwort bestätigt wird. Fiddler oder Wireshark können die Pakete sehr einfach mitschneiden und decodieren. Hier sehen Sie eine Anfrage an die Symantec PKI.

 

Die Anfrage ist eigentlich nur ein GET-Request, der in dem Beispiel 232 Bytes lang ist.

Das Antwortpaket enthält den Status und ist selbst mit dem Zertifikat der PKI signiert. Es sollte also nicht zu fälschen sein, sofern die PKI vertrauenswürdig ist.

Aber letztlich bauen alle Zertifikat auf das Vertrauen des Clients auf die PKI.

Schwächen

Das Funktionsprinzip ist auf jeden Fall besser als eine CRL-Liste, da die Abfragen viel weniger Bandbreite benötigen und eine PKI ein zurückgezogenes Zertifikat sehr schnell als ungültig kennzeichnen kann. Wobei hier Symantec mit einer Gültigkeitsdauer von 7 Tagen aus meiner Sicht sehr groß gewählt ist. Aber es gibt auch hier Aspekte, die nicht unterschlagen werden dürfen.

  • Problem 1: die PKI muss viele Webanfragen verkraften
    Statt weniger CRL-Abfragen, die ein HTTP-Proxy oder Provider sogar cachen kann (da HTTP statt HTTPS) sind nun sehr viele kleine Anfragen zu bedienen. Für die PKI ist das immer noch ein Thema, wenn auch dieses Dienstleistung muss im Preis für das ausgestellte Zertifikat ja eingerechnet werden. Für eine kleine Blog-Site mit wenig Zugriffen kann eine PKI das sicher problemlos Querfinanzieren. Wenn aber große Sites mit viel Besuch signiert werden, dann muss die PKI schon eine gewisse Leistung erbringen
  • Problem 2: Softfail bei „Störung“ der PKI
    Wenn ein Client auf eine CRL oder OCSP-Anfrage keine Antwort bekommt, dann gehen leider die meisten Clients von einem "Soft-FAIL" aus, d.h. die TLS-.Verbindung wird dennoch ohne Warnung aufgebaut. Das öffnet natürlich die Tür für Angreifer, die einem Client zuerst ein falsches Zertifikat unterschieben und dann die CRL/OSCP-Prüfung verhindern.
  • Problem 3: Die PKI „sieht“ die Anfragen
    Ein Datenschutz-Thema ist die Prüfung der CRL und OCSP-URLs. Jeder Client, der ein Ziel per TLS (HTTPS, POP3S, IMAP4S, SMTPS u.a.) anspricht und die PKI anfragt, hinterlässt dort eine Spur. Der Betreiber der PKI kann also sehr genau anhand dieser Abfragen ermitteln, welcher Client welche Ziele ansprechen. Die PKI weiß ja welche Zertifikate auf welchen Namen ausgestellt wurden.

Auch wenn OCSP schon mal besser ist als eine CRL so sind die Probleme durchaus nicht zu verheimlichen.

OCSP Stapling

Sicher auch deswegen hat sich das "OCSP Stapling"-Verfahren entwickelt, bei dem nun der Webserver anstelle des Clients den OCSP-Status überprüft und die signierte OCSP-Antwort schon mit dem TLS-Handshake an den Client ausliefert. Der Ablauf ist dann wie folgt:

  1. Client-A initiiert eine TLS Verbindung zu Server-B
    Soweit hat sich noch nichts zur OCSP-Anfrage geändert.
  2. Server-B fragt die PKI-C nach einer Signierung der OCSP-Anfragen
    Natürlich kann der Server die Antworten von vorherigen Anfragen auch cachen, so dass die OCSP-Anfragen nicht bei jeder einzelnen Anfrage erforderlich ist. Aber diese Zeit kann auch mal in Stunden oder Minuten anstelle von Tagen konfiguriert werden
  3. PKI-C sendet die signierte OCSP-Antwort an Server B
    Die PKI bekommt also vielleicht einmal pro Stunde die Anfrage nach dem OCSP-Status des Zertifikats. Der eigene Server kann sofort erkennen, wenn die OCSP-Anfrage negativ beschieden wird und den Betreiber alarmieren, dass die PKI das Zertifikat als ungültig gekennzeichnet hat.
  4. Server B liefert TLS-Zertifikat UND die signierte OCSP-Antwort
    Schon im Rahmen des TLS-Handshake liefert der Server nun sein Zertifikat und die OCSP-Bestätigung der ausstellenden PKI mit aus.
  5. Client startet TLS-Datenaustausch
    Der Client muss also selbst gar nicht mehr eine OCSP-Anfrage stellen, was die PKI und den Client entlastet und vor allem es quasi unmöglich macht, dass ein Angreifer den OCSP-Check durch den Client unterbindet

Die Vorteile dieses alternativen Verfahrens sind nicht von der Hand zu weisen. Allerdings muss natürlich der Server nun per OCSP mit der PKI sprechen können und überhaupt OCSP Staping unterstützen. Auch der Client muss natürlich OCSP Stapling unterstützen. das ist aber gar nicht mal so selten. Das Verfahren ist schon etwas älter und eigentlich kann jeder Browser seit Windows Vista damit umgehen und auch der IIS ab Windows 2008.

Kurz und sehr kurz gültige Zertifikate (Let's encrypt)

Es gibt natürlich noch eine weitere Option, die Thematik der Rückruflisten per CRL oder OCSP ganz zu vermeiden oder zumindest zu entspannen. Was sollte Sie hindern, ein Zertifikat zu verwenden, welches nur wenige Tage gültig ist und ein Enrollment automatisch erfolgt? Genau dies wird z.B. durch Let's Encrypt vorgemacht. Kurz gültige Zertifikate werden einfach ersetzt und nicht lange zurückgerufen. Ein abgelaufenes Zertifikat muss auch nicht mehr in einer CRL oder OCSP-Anfrage auftauchen, was die Belastung der PKI-Server und Clients natürlich ebenfalls reduziert.

Allerdings sind Zertifikate von Let's Encrypt in der Regel 90 Tage gültig. Das ist kurz genug um die CRLs kompakt zu halten aber wäre dennoch für einen geschäftlichen Einsatz zu lange, wenn es keine CRL/OCSP-Möglichkeit gibt. Daher nutzt auch Let's Encrypt OCSP.

Weitere Links