Sicherheitshinweise

Zusammenfassung

Am 13. Oktober 2016 gegen 11:10 Uhr GMT traten bei Nutzern, die Websites mit GlobalSign TLS Zertifikaten besuchten – darunter auch einige, die von Fastly gehostet wurden – Fehler bei der TLS-Zertifikatvalidierung auf. Dieses Problem wurde durch falsche Zertifikatswiderrufsinformationen verursacht, die von unserem Zertifikatanbieter, GlobalSign, veröffentlicht wurden.

Dieser Sicherheitshinweis beschreibt die Ursache dieses Problems und die Maßnahmen, die Fastly ergriffen hat, um die Auswirkungen bei den Kunden zu begrenzen.

Auswirkungen

Bei manchen Website-Besuchern kam es möglicherweise zu Fehlern bei der Zertifikatvalidierung, wie beispielsweise „NET::ERR_CERT_REVOKED“, wenn sie auf bestimmte Websites mit GlobalSign Zertifikaten zugriffen.

Diese Störung betraf Fastly Kunden, da einige unserer TLS-Optionen Zertifikate verwenden, die Fastly für sie von unserem TLS-Zertifizierungsstellenanbieter GlobalSign beschafft hatte. Zum Beispiel verwenden Kunden, die gemeinsam genutzte Zertifikate von Fastly verwenden, automatisch Zertifikate, die von GlobalSign ausgestellt wurden.  Kunden, die unser Kundenzertifikat-Hosting oder SNI-Kundenzertifikat-Hosting mit Zertifikaten nutzen, die von einem anderen Anbieter als GlobalSign ausgestellt wurden, waren von dem Problem nicht betroffen.

Die Fehler wären inkonsistent gewesen und nur eine kleine Anzahl von Nutzern hätte falsche OCSP-Antworten erhalten. Das Problem konnte für Kunden bis zu vier Tage lang bestehen, wenn ihr lokaler Rechner den OCSP-Eintrag zwischengespeichert hatte. Fastly hat seinen Traffic zum Zeitpunkt der Störung überprüft und konnte keinen nennenswerten Rückgang des Traffics bei seinen Kunden feststellen.

Einzelheiten

Ursache

Um den 7. Oktober 2016 herum entfernte die Zertifizierungsstelle GlobalSign ein Cross-Zertifikat und gab eine Certificate Revocation List (CRL) heraus, in der dieser Widerruf gelistet war. Aufgrund eines technischen Fehlers bei der Kompilierung von Online Certificate Status Protocol (OCSP)-Antworten seitens GlobalSign gab der OCSP-Responder des Unternehmens ab dem 13. Oktober 2016 ungenaue Antworten für eine Reihe von Zwischenzertifikaten zurück. Daraus folgerten einige Browser, dass mehrere von GlobalSign ausgestellte Zwischenzertifikate widerrufen worden waren.

Diese Informationen wurden über die OCSP (Online Certificate Status Protocol) -Responder von GlobalSign verbreitet und in einigen Fällen von einem zwischengeschalteten, nicht von Fastly betriebenen CDN sowie auf Client-Systemen zwischengespeichert.

Diese falschen OCSP-Antworten führten bei einigen Web-Nutzern zu Fehlern bei der Zertifikatvalidierung von Websites, die GlobalSign Zertifikate nutzen, darunter auch viele von Fastly gehostete Services. Die Fehler führten dazu, dass Nutzer Zertifikatsausfälle akzeptieren mussten, bevor sie auf die Ziel-Website zugreifen konnten, oder dass ein Zugriff gar nicht erst möglich war.

Die Fehler traten nicht immer auf und betrafen auch nicht alle Nutzer, da nicht alle Browser OCSP validieren, bevor sie den Zugriff auf eine Website zulassen. Das Problem hatte keine Auswirkungen auf andere Mechanismen zur Angabe der Gültigkeit, wie z. B. Certificate Revocation Lists (CRL).

Unsere Abwehr und Reaktion

Nachdem wir über das Problem informiert worden waren, haben wir GlobalSign kontaktiert. GlobalSign führte eine Untersuchung durch, ermittelte die Grundursache und löste das Problem, indem es die falschen OCSP-Antworten entfernte.

Zu diesem Zeitpunkt wurden falsche Antworten jedoch auf mehreren Ebenen zwischengespeichert, darunter im lokalen OCSP-Cache, der Teil des Betriebssystems ist. Die OCSP-Antworten werden üblicherweise bis zum Ende ihrer Gültigkeit gespeichert; GlobalSign gibt OCSP-Antworten mit einer Gültigkeit von vier Tagen aus, was bedeutet, dass sie, sobald sie von einem Client empfangen wurden, vom Client als für volle vier Tage gültig angesehen werden.

Der OCSP-Responder von GlobalSign verwendete ein anderes CDN als Fastly, das möglicherweise Antworten zwischengespeichert hat und dazu führte, dass ihr Responder Fehler zurückgab, selbst nachdem die Grundursache schon behoben war. Aufgrund des Caching-Verhaltens von Client-Betriebssystemen haben außerdem einige Client-Rechner, die mit einer fehlgeschlagenen OCSP-Antwort auf Websites zugegriffen hatten, diese Antwort weiterhin im Cache gespeichert. Dies führte dazu, dass Clients auf diesen Rechnern nicht in der Lage waren, auf betroffene Websites zuzugreifen, selbst nachdem das Problem von GlobalSign behoben worden war.

Obwohl Nutzer den OCSP-Cache auf ihren Rechnern manuell leeren können und GlobalSign ihnen dazu eine Anleitung zur Verfügung gestellt hatte, ging dies über die technischen Fähigkeiten der meisten Endnutzer hinaus. Außerdem waren die von GlobalSign zur Verfügung gestellten Behelfslösungen nicht in allen Situationen effektiv.

Fastly hielt diese Abwehr, die an die Endnutzer unserer Kunden weitergegeben werden sollte, nicht für ausreichend. Nach sorgfältiger Untersuchung bot Fastly seinen Kunden eine weitere Option zur Problemlösung an:

• Kunden mit einer dedizierten Karte konnten auf ein neues Zertifikat von einem GlobalSign-Zwischenprodukt wechseln, das nicht von dem Problem betroffen war. Da der zwischengespeicherte Eintrag nur für das alte Zertifikat gelten würde, wurde das Problem dadurch für diese Kunden vollständig behoben;


• Kunden mit einem gemeinsam genutzten Zertifikat könnten zu weiteren gemeinsam genutzten Endpunkten mit ähnlichen neu ausgestellten Zertifikaten wechseln. Kunden, die uns kontaktierten und Probleme meldeten, wurde angeboten, auf das neue Mapping zu wechseln.

Wir waren nicht in der Lage, ohne die Mitarbeit unserer Kunden Maßnahmen zu ergreifen, um die Ursache zu beheben, da uns bekannt ist, dass einige Kunden das Zertifikats-Pinning (siehe „Weitere Informationen“ unten) in ihrer Client-Anwendung nutzen. Aus diesem Grund konnten wir Bestandskunden ohne ihre Mitarbeit nicht einfach direkt auf ein neues Zwischenzertifikat umstellen.

Fix/Behelfslösung

Widerrufsfehler sollten nach Ablauf der Gültigkeit der OCSP-Antwort gelöscht werden, also vier Tage nach der ursprünglichen Störung. Bei Kunden, die auf die von Fastly bereitgestellten aktualisierten Karten gewechselt haben, war das Problem kurz nach der Umstellung behoben.

Fastly ist sich bewusst, dass Kunden sich sowohl auf Drittanbieter-Zertifizierungsstellen als auch auf das CDN verlassen, um den Nutzerverkehr erfolgreich zu akzeptieren und zu senden. Als Lehre aus diesem Ereignis arbeiten wir an den folgenden Schritten zur Abhilfe und Abwehr:

• Sicherstellung, dass unsere Pläne zur Störungsbehebung Ausfälle von Drittanbietern bei der Bereitstellung von TLS-Zertifikaten als möglichen Grund für einen Ausfall bei Kunden berücksichtigen. Infolge dieses Ereignisses haben wir die notwendige Infrastruktur für eine schnelle Migration über TLS-Hierarchien hinweg eingerichtet und werden auch weiterhin zusätzliche Notfallpläne in Bezug auf diese Drittanbieter einrichten.


• Die Statusseite von Fastly unter status.fastly.com verwendete ein GlobalSign-Zertifikat und war während der Störung womöglich auf ähnliche Weise betroffen. Wir überprüfen unsere Mechanismen zur Statusmeldung, um sicherzustellen, dass sie nicht auf kritische Services angewiesen sind, die die Bereitstellung von Inhalten über das CDN direkt beeinflussen würden, wobei es sich in diesem Fall um die gleiche Zertifizierungsstelle handelt; und


• Evaluierung von Möglichkeiten zusammen mit GlobalSign, um die Zuverlässigkeit der Bereitstellung von OCSP-Antworten für GlobalSign-Zertifikate für Fastly Kunden zu erhöhen.

Wir arbeiten mit unserem Anbieter GlobalSign zusammen, um sicherzustellen, dass Pläne ausgearbeitet werden, um zukünftige Ereignisse in Zusammenhang mit der Ausstellung und dem Widerruf von Zertifikaten abzuwehren.

Weitere Informationen

Hintergrund zur Zertifikatvalidierung und Überprüfung von Widerrufen

Wenn ein Browser eine Verbindung zu einer Website herstellt und ein X.509-Zertifikat evaluiert, versucht der Browser normalerweise sicherzustellen, dass das Zertifikat noch gültig ist. Um dies zu unterstützen, erlaubt X.509 der Zertifizierungsstelle, die Gültigkeit auf verschiedene Weise zu bestätigen. Im Folgenden finden Sie eine Erläuterung, die Ihnen hilft zu verstehen, warum bestimmte Kunden von Problemen durch diese Störung betroffen waren und andere nicht. Im Prinzip wären die meisten Probleme den Nutzern aufgefallen, deren Browser oder Betriebssystem mit interaktiven OCSP-Anfragen arbeitet:

1. CRL: Zertifizierungsstellen veröffentlichen Certificate Revocation Lists (CRLs). Dabei handelt es sich um Dateien, die Listen von Zertifikaten enthalten, die von der Zertifizierungsstelle widerrufen wurden. Die meisten Browser laden die CRL nicht interaktiv bei jeder Anfrage herunter, da die Datei in der Regel sehr groß ist und das Herunterladen und Validieren bei jeder Verbindung erhebliche Leistungseinbußen zur Folge hätte.


2. CRLSets: Google Chrome verwendet CRLSets als Methode zum schnellen Blockieren von Zertifikaten. Chrome führt im Allgemeinen keine interaktiven OCSP- und CRL-Prüfungen durch, obwohl bestimmte Betriebssystembibliotheken diese Prüfungen möglicherweise auf einem System durchführen, das Chrome für den Zugriff auf eine Webseite verwendet. Google geht diese CRL-Listen, die von Zertifizierungsstellen veröffentlicht werden, durch, extrahiert die für sie wichtigen und stellt sie für den automatischen Download durch Chrome-Browser zur Verfügung.


3. OCSP: Zertifizierungsstellen aktivieren auch einen Online Certificate Status Protocol (OCSP)-Responder, der interaktiv von einem Browser abgefragt werden kann, um zu überprüfen, ob ein Zertifikat noch gültig ist. Viele Browser führen bei der Validierung eines TLS-Zertifikats interaktiv eine OCSP-Prüfung durch. Wenn eine OCSP-Antwort empfangen wird, wird das Ergebnis – egal, ob positiv (gültig) oder negativ (ungültig) – in einem lokalen OCSP-Cache-Teil des Betriebssystems zwischengespeichert. Antworten werden üblicherweise bis zum Ablauf der Gültigkeit der OCSP-Antworten gespeichert, welche im Fall von GlobalSign vier Tage betrug.


4. OCSP -Stapling: OCSP-Antworten können auch vom Webserver über eine Methode namens „OCSP-Stapling“ geliefert werden. Dabei wird die von der Zertifizierungsstelle signierte Gültigkeitsbestätigung vom Webserver abgerufen und beim TLS-Handshake „angeheftet“. OCSP-Stapling hat sowohl Leistungs- als auch Sicherheitsvorteile, da eine separate Verbindung zum OCSP-Responder der Zertifizierungsstelle nicht mehr erforderlich ist. Dieses „Stapling“ oder Anheften ist eine bewährte Praxis für den Widerruf von Zertifikaten und wird in der gesamten Flotte von Fastly eingesetzt.

Browser können zusätzlich zur Gültigkeitsprüfung auch durch „Public Key Pinning“ prüfen, ob ein Zertifikat für eine bestimmte Site gültig ist. Bei dieser Methode wird die Client-Anwendung (App oder ein Browser) darauf geprüft, ob das Root-, Zwischen- oder Anwender-Zertifikat eines Services zu erwarten ist. Pins können im Client fest kodiert sein oder über die Public Key Pinning-Erweiterung für HTTP (HPKP) verteilt werden. Pinning ist eine wertvolle und häufig verwendete Sicherheitsfunktion, die das Risiko verringert, dass eine Zertifizierungsstelle unterwandert wird, um ein ansonsten gültiges Zertifikat für einen Service auszustellen. Allerdings kann Pinning auch die Flexibilität einer Website einschränken, schnell zu einer anderen Zertifikatshierarchie wechseln zu können. Bei dieser Störung schränkte die mögliche Verwendung von Pinning durch unsere Kunden die Fähigkeit von Fastly ein, alle Kunden automatisch und transparent in eine andere Hierarchie zu migrieren.

Störungsbericht von GlobalSign

GlobalSign hat unter https://www.globalsign.com/en/customer-revocation-error/ einen Störungsbericht mit Informationen über ihre Reaktion auf die Störung veröffentlicht. Dieses Dokument enthält weitere Informationen über die von GlobalSign unternommenen Schritte, um eine Wiederholung dieser Art von Störungen zu verhindern.