Online Certificate Status Protocol stapling

Online Certificate Status Protocol stapling, formell bekannt als die TLS-Zertifikatsstatusabfrage-Erweiterung, ist ein alternativer Ansatz zum Online Certificate Status Protocol (OCSP) um den Gültigkeitsstatus von digitalen Zertifikaten nach X.509 zu prüfen.[1] Es ermöglicht dem Zertifizierten, die Aufgabe der Zertifikatsvalidierung zu übernehmen, indem er eine von der Zertifizierungsstelle signierte OCSP-Antwort mit Zeitstempel an den ursprünglichen TLS-Handshake anhängt („stapling“). Dieses Verfahren verringert den Kommunikationsaufwand zwischen Clients und Zertifizierungsstellen deutlich.[2][3]

Motivation

Bearbeiten

OCSP stapling löst die meisten Probleme mit der ursprünglichen OCSP-Implementierung.[3]

Die ursprüngliche OCSP-Implementierung kann zu beträchtlichen Kosten für die Zertifizierungsstellen führen, da diese dabei für ein bestimmtes Zertifikat jedem Client in Echtzeit Antworten liefern müssen. Wenn beispielsweise eine Website mit hohem Verkehrsaufkommen ein Zertifikat ausgestellt bekommt, dann werden die Server der Zertifizierungsstelle wahrscheinlich von einem starken Aufkommen an OCSP-Anfragen getroffen, die die Gültigkeit des Zertifikates abfragen.[4]

OCSP-Prüfungen schädigen potenziell die Privatsphäre des Nutzers und bremsen das Browsen, da der Client eine weitere Partei (die Zertifizierungsstelle) kontaktieren muss, um die Echtheit eines jeden Zertifikates zu bestätigen, dem er begegnet.[4]

Weiterhin hat der Client die Wahl zwischen zwei gleichermaßen unerwünschten Möglichkeiten, falls die Kontaktaufnahme zu der Zertifizierungsstelle scheitert. Der Client kann entweder mit der Verbindung fortfahren und damit auf den Zweck der Widerrufsprüfung über OCSP verzichten oder unter Annahme eines Angriffes die Verbindung beenden, was die Benutzerfreundlichkeit senkt und zu übermäßig vielen fehlerhaften Warnungen und Sperren führen kann.[5]

OCSP stapling löst beide Probleme auf eine Weise, die an das Kerberos-Ticket erinnert. In einem Anhänge-Szenario („stapling“) fragt der Zertifikatsinhaber selbst in regelmäßigen Abständen beim OCSP-Server an und erhält eine signierte OCSP-Antwort mit Zeitstempel. Wenn die Besucher der Seite versuchen, sich zu verbinden, wird diese Antwort über die Zertifikatsstatusabfrage-Erweiterung an den TLS/SSL-Handshake angehängt („stapled“). (Merke, dass der TLS-Client ausdrücklich eine Zertifikatsstatusabfrage-Erweiterung in seiner ClientHello-Nachricht beim TLS-Handshake integrieren muss.)[6] Wenngleich es so scheint, als wenn es dem Betreiber einer missbräuchlichen Site ermöglichen würde, falsche Bestätigungen für ein zurückgezogenes Zertifikat auszugeben, wenn er die Antworten für die Überprüfung beeinflussen kann, so können die angehängten Prüfnachrichten nicht gefälscht werden, da sie direkt von der Zertifizierungsstelle und nicht vom Server signiert werden müssen.[3] Wenn der Client keine angehängte Prüfnachricht erhält, so kann er einfach selbst beim OCSP-Server anfragen.[5] Wenn er allerdings eine ungültige angehängte Prüfnachricht erhält, so bricht er die Verbindung ab.[1] Die einzige durch OCSP stapling vergrößerte Gefahr ist, dass die Rückzugsbenachrichtigung für ein Zertifikat verzögert werden kann, bis die zuletzt signierte OCSP-Antwort abläuft.

Folglich haben Clients weiterhin nachprüfbare Versicherung von der Zertifizierungsstelle, dass das Zertifikat gültig ist (oder kürzlich war), müssen jedoch nicht mehr einzeln bei dem OCSP-Server anfragen. Dies bedeutet, dass der Großteil der Last wieder auf den Zertifikatsinhaber entfällt. Es bedeutet auch, dass die Client-Software das Nutzerverhalten nicht mehr einer Drittpartei offenlegen muss.[4]

Die Leistung insgesamt wird auch verbessert: Wenn der Client die OCSP-Antwort direkt von der Zertifizierungsstelle abholt, so impliziert das gewöhnlich das Nachschlagen des Domain-Namens des OCSP-Servers bei dem DNS sowie den Aufbau einer Verbindung zum OCSP-Server. Bei der Nutzung von OCSP stapling werden die Informationen über den Status des Zertifikates über einen bereits etablierten Kanal ausgeliefert, was den Overhead reduziert und die Leistung verbessert.[2]

Spezifikation

Bearbeiten

Die TLS-Zertifikatsstatusabfrage-Erweiterung ist in Abschnitt 8 von RFC 6066[7] spezifiziert.

RFC 6961[8] beschreibt eine Zertifikatsstatusabfrage-Erweiterung für mehrere Zertifikate, die dem Server den Versand mehrerer OCSP-Antworten in einem TLS-Handshake ermöglicht.

Ein Entwurf eines Vorschlages für ein X509v3-Erweiterungsfeld, welcher im April 2013 abgelaufen ist, legt fest, dass ein kompatibler Server, der ein Zertifikat mit dieser Erweiterung vorlegt, in seiner Antwort ein gültiges OCSP-Token liefern muss, wenn die status_request-Erweiterung in der ClientHello-Nachricht von TLS angegeben ist.[9] Die aktuelle Version des Vorschlages wurde erweitert, um weitere TLS-Erweiterungen zu unterstützen.[10] Der TLS-Entwickler Adam Langley behandelt die Erweiterung in einem Artikel vom April 2014 nach der Reparatur des Heartbleed-Fehlers in OpenSSL.[11]

Unterstützung für OCSP stapling wird nach und nach umgesetzt. Das OpenSSL-Projekt fügte Unterstützung mithilfe finanzieller Unterstützung von der Mozilla Foundation in der Veröffentlichung 0.9.8g hinzu.

Der Apache HTTP Server unterstützt OCSP stapling ab Version 2.3.3,[12] der Webserver nginx ab Version 1.3.7,[13] der LiteSpeed Web Server ab Version 4.2.4,[14] Microsofts IIS seit Windows Server 2008,[15] HAProxy ab Version 1.5.0[16] und F5 Networks BIG-IP ab Version 11.6.0.[17]

Auf Browser-Seite wurde OCSP stapling in Firefox 26 eingebaut,[5][18] in Internet Explorer seit Windows Vista[19] und Google Chrome unter Linux, Chrome OS und Windows seit Vista.[20]

Für SMTP unterstützt der Exim message transfer agent OCSP stapling sowohl im Client-[21] als auch im Server-[22] Modus.

Beschränkungen

Bearbeiten

OCSP stapling ist für die Reduktion der Kosten der OCSP-Validierung entwickelt – sowohl für den Client als auch für den OCSP-Responder – besonders für große Websites, die viele Nutzer gleichzeitig bedienen. Trotzdem unterstützt OCSP stapling nur die Auslieferung jeweils einer OCSP-Antwort, was bei Ketten mit Zwischenzertifikaten nicht ausreichend ist.[23][24]

Dieser Beschränkung wurde durch eine Zertifikatsstatusabfrage-Erweiterung für mehrere Zertifikate begegnet, die in RFC 6961[8] festgelegt ist. Sie ergänzt den gleichzeitigen Versand mehrerer OCSP-Antworten.[25]

Einzelnachweise

Bearbeiten
  1. a b D. Eastlake: RFC 6066 – Transport Layer Security (TLS) Extensions: Extension Definitions. Januar 2011 (englisch).
  2. a b Matthew Prince: (29. Oktober 2012).
  3. a b c Steve Gibson:
  4. a b c A. Jesin (12. Juni 2014).
  5. a b c David Keeler: (29. Juli 2013).
  6. OCSP Stapling. globalsign.com
  7. D. Eastlake: RFC 6066 – Transport Layer Security (TLS) Extensions: Extension Definitions. Januar 2011, Abschnitt 8 (englisch).
  8. a b Y. Pettersen: RFC 6961 – The Transport Layer Security (TLS) Multiple Certificate Status Request Extension. Juni 2013 (englisch).
  9. P. Hallam-Baker: X.509v3 Extension: OCSP Stapling Required. IETF.
  10. P. Hallam-Baker: X.509v3 TLS Feature Extension draft-hallambaker-tlsfeature-05. IETF.
  11. A. Langley: No, don’t enable revocation checking. imperialviolet.org, 19. April 2014.
  12. Apache HTTP Server mod_ssl documentation – SSLUseStapling directive
  13. nginx-announce mailing list – nginx-1.3.7
  14. Release Log – Litespeed Tech.
  15. Robert Duncan:
  16. HAProxy website
  17. Release Note: BIG-IP LTM and TMOS 11.6.0
  18. Improving Revocation – MozillaWiki, abgerufen am 28. April 2014.
  19. How Certificate Revocation Works.
  20. Issue 361820: Check For Server Certificate Revocation checkbox is confusing. code.google.com
  21. The smtp transport, abgerufen am 24. Januar 2015.
  22. Main configuration. exim.org; abgerufen am 24. Januar 2015.
  23. Adam Langley: Kommentar zu Mozilla NSS Bug 360420.
  24. Mozilla NSS Bug 611836 – Implement multiple OCSP stapling extension.
  25. Yngve N. Pettersen: (Juni 2013).