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.
Übersicht: SSL / TLS
- TLS - Transport Layer Security
- Schwachstellen von SSL/TLS
- HTTPS / HTTP Secure
- HSTS - HTTP Strict Transport Security
- PFS - Perfect Forward Secrecy
- HPKP - HTTP Public Key Pinning
- CA-Pinning / Certification Authority Authorization
- CT - Certificate Transparency
- DANE - DNS-based Authentication of Named Entities
- Analyse von SSL/TLS-Verbindungen
Weitere verwandte Themen:
Frag Elektronik-Kompendium.de
Netzwerktechnik-Fibel
Alles was Sie über Netzwerke wissen müssen.
Die Netzwerktechnik-Fibel ist ein Buch über die Grundlagen der Netzwerktechnik, Übertragungstechnik, TCP/IP, Dienste, Anwendungen und Netzwerk-Sicherheit.
Artikel-Sammlungen zum Thema Netzwerktechnik
Collection: Netzwerk-Grundlagen
Was du über Netzwerk-Grundlagen wissen solltest.
Schützen Sie Ihr Netzwerk
Die TrutzBox enthält einen leistungsstarken Content-Filter, der Werbetracker blockiert und vor Schadcode auf bösartigen Webseiten schützt.
Alle Internet-fähigen Geräte, egal ob Desktop-PCs, vernetzte Produktionsanlagen und IoT-Geräte, werden vor Überwachung durch Tracker, Einschleusen von Schadsoftware und dem unbedachten Zugriff auf bösartige Webseiten geschützt.
- Sicheres Surfen mit Content-Filter und Blocker gegen Werbetracker
- Mehrstufige Sicherheitsarchitektur mit Stateful-Inspection-Firewall und Intrusion-Prevention-System
- Laufende Aktualisierung gegen neue Bedrohungen
Bestellen Sie Ihre TrutzBox mit integriertem Videokonferenz-Server jetzt mit dem Gutschein-Code "elko50" und sparen Sie dabei 50 Euro.
Mehr über die TrutzBox TrutzBox jetzt mit Gutschein-Code bestellen