OCSP - Online Certificate Status Protocol
Das Online Certificate Status Protocol, kurz OCSP, ist ein Protokoll, um festzustellen, ob ein Zertifikat widerrufen bzw. gesperrt wurde.
Wenn geheime Schlüssel öffentlich oder geklaut werden, dann muss das dazugehörige Zertifikat beim verantwortlichen Herausgeber, der Certification Authority (CA) bzw. Zertifizierungsstelle, gesperrt werden.
Beim Eingang eines Zertifikats durch SSL bzw. TLS, prüft der Client über die Certificate Revocation Lists (CRLs) des Herausgebers, ob ein Zertifikat noch gültig ist. Diese Listen sind allerdings mehrere MByte groß und werden schnell größer. Für eine schnelle Prüfung sind diese Listen nicht geeignet, weil die erst vom Client heruntergeladen werden müssen.
Deshalb arbeiten Clients mit OCSP, um den Status eines bestimmten Zertifikats beim Herausgeber zu erfragen. Damit das gelingt müssen Zertifikate einen OCSP-Eintrag aufweisen. Ist ein Zertifikat gesperrt erfährt das ein Client nur dann, wenn es eine erfolgreiche OCSP-Anfrage durchführt.
Unterstützung in den Browsern
- Mozilla Firefox (aktiviert)
- Microsoft Internet Explorer (aktiviert)
- Google Chrome (deaktiviert)
Wie sicher ist OCSP?
OCSP hat einen Konstruktionsfehler, der dazu führt, dass das Sperren von Zertifikaten eigentlich nicht funktioniert. Das heißt, ein Zertifikat wird akzeptiert, obwohl es zwischenzeitlich zurückgezogen bzw. gesperrt wurde.
Wie kann das sein? Der Haken an OCSP ist der, dass ein Browser einen unbeantworteten OCSP-Request als ein "OK" akzeptiert. Das bedeutet, dass ein Browser ein Zertifikat als gültig akzeptiert, das nicht vollständig geprüft werden kann. Doch warum ist das so?
- Weil ein OCSP-Request den Verbindungsaufbau zu verschlüsselten Webseiten verlängert. Neben dem HTTPS-Request und dem darauffolgenden SSL/TLS-Verbindungsaufbau muss auch noch ein OCSP-Request erfolgen, was den Seitenaufbau verzögert. Und das möchte man den Nutzern nicht zumuten. Die Browser-Hersteller wollen natürlich nicht für ein langsames Internet verantwortlich sein.
- Außerdem muss man berücksichtigen, dass der Ausfall eines einzigen OCSP-Servers große Teile des Internets lahmlegen würde. Da würde schon eine gezielte DDoS-Attacke auf einen solchen Server ausreichen und schon wäre er nicht mehr erreichbar.
Zusammenfassend kann man sagen, dass wenn ein Browser nach einem OCSP-Request nicht innerhalb einer bestimmten Zeit einen Response bekommt, dann ignoriert er diesen Zustand einfach und akzeptiert ein Zertifikat als gültig, obwohl es zwischenzeitlich vielleicht gesperrt wurde. Das machen alle Browser so, weil die Infrastruktur einfach nicht verlässlich genug ist und es zu viele Fehlalarme geben würde.
OCSP-Anfragen verzögern auf der einen Seite den Seitenaufbau. Und auf der anderen Seite tragen sie zum Schutz vor Angriffen wenig bei. Was der Art und Weise geschuldet ist, wie die Prüfung umgesetzt ist.
Der Nutzen von OCSP ist auch deshalb fragwürdig, weil ein Angreifer, der per Man-in-the-Middle eine verschlüsselte Verbindung umleiten und übernehmen kann und dazu ein gesperrtes Zertifikat benutzt, auch ohne Probleme die OCSP-Kommunikation unterbinden kann. In so einem Fall würde der Client das Zertifikat akzeptieren und nicht bemerken, dass etwas nicht stimmt.
Das für einen sicheren Betrieb erforderliche Sperren von Zertifikaten in SSL bzw. TLS funktioniert also nicht wirklich. Es gibt keinen wirklich funktionierenden Sperrmechanismen für Server-Zertifikate. Der Grund, weil überhaupt keine wirksame Prüfung von Zertifikaten stattfindet. Das bemerkenswerte daran ist, dass das die Öffentlichkeit ignoriert.
Um es kurz und knapp auszudrücken, OCSP ist ziemlicher Schrott. Doch wie kann man das lösen?
Ein Beispiel: Google arbeitet bei seinem Browser Chrome nicht mit OCSP, sondern mit so genannten CRLSets. Bei denen erhält der Browser über den Update-Mechanismus die wichtigsten Einträge der Sperrlisten. Leider funktioniert das bei Massensperrungen, wie sie beim Heartbleed-Bug (OpenSSL) auftraten, nicht zuverlässig.
Eine weitere Alternative wären kurzlebige Zertifikate und OCSP Stapling.