en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Optimierung des Seitenladens: OCSP-Heften

Einführung

Wenn ein Benutzer Ihre HTTPS-Website besucht, muss er mit einer Funktion antworten Öffentlicher Schlüsselund ein gültiges SSL-Zertifikat, das den Schlüssel mit Ihrer Identität als Person, Unternehmen oder Organisation verknüpft. Zertifikate werden immer mit einem vordefinierten Ablaufdatum ausgestellt, das im signierten Zertifikat selbst enthalten ist. Browser überprüfen immer das Ablaufdatum und lehnen abgelaufene Zertifikate ab.

In bestimmten Fällen muss ein Zertifikat jedoch als ungültig markiert sein (und das Vertrauen in diese Zertifikate muss bestehen widerrufen) Vor es läuft ab. Zu den gängigen Beispielen gehört ein Serverbesitzer, der Beweise (oder einfach den Verdacht) hat, dass sein privater Schlüssel kompromittiert wurde (dh verloren gegangen, gestohlen oder zerstört wurde), da ein Dritter, der diesen privaten Schlüssel besitzt, im Wesentlichen alle Sicherheitskontrollen des Browsernetzwerks umgehen kann.

Infolgedessen sind Browser-Anbieter erforderlich öffentlich vertrauenswürdig Zertifizierungsstellen (Zertifizierungsstellen) mindestens eine Methode zu implementieren, um problematische Zertifikate zu widerrufen und Browser zu benachrichtigen, diese widerrufenen Zertifikate abzulehnen.

Beispiele für Browserfehlermeldungen aufgrund von widerrufenen Zertifikaten finden Sie unter dieser Leitfaden. Sie können den Widerrufsstatus eines Zertifikats unter überprüfen ificate.revocationcheck.com.

Eine kurze Geschichte der (Probleme der) Widerrufsprüfung

In den frühen Tagen von SSL bestand die Methode der Zertifizierungsstellen darin, ihren Status zum Widerruf von Zertifikaten in öffentlich zugänglichen Dokumenten zu veröffentlichen, die aufgerufen wurden Sperrlisten für Zertifikate (CRL). Eine CRL ist einfach eine Liste aller Zertifikate, die eine Zertifizierungsstelle vor Ablauf jemals widerrufen hat. CAs veröffentlichten regelmäßig die neueste Version ihrer CRLs, mit denen sich die Browser beraten mussten Vor jede HTTPS-Verbindung.

Natürlich als HTTPS (und SSL /TLS) Die Akzeptanz nahm im Laufe der Jahre zu, ebenso wie die Größe der veröffentlichten CRLs. Das Erfordernis, vor jeder Verbindung eine große CRL herunterladen und analysieren zu müssen, führte zu einem ständig wachsenden Netzwerk-Overhead. Es stellte sich schnell heraus, dass die CRL-Methode nicht gut skaliert.

Um diese Skalierungsprobleme zu verringern, haben Browser und Zertifizierungsstellen die Online-Zertifikatstatusprotokoll (OCSP). Öffentlich vertrauenswürdige Zertifizierungsstellen wie z SSL.com, pflegen jetzt einfache HTTP-Server namens OCSP-Responder. Browser können sich jetzt an einen Antwortenden wenden, um den Widerrufsstatus eines einzelnen von der Zertifizierungsstelle ausgestellten Zertifikats anzufordern, anstatt die gesamte CRL erwerben und verarbeiten zu müssen.

OCSP-Responder signieren ihre Antworten mit dem privaten Signaturschlüssel der Zertifizierungsstelle, und Browser können überprüfen, ob der erhaltene Sperrstatus tatsächlich von der tatsächlichen Zertifizierungsstelle generiert wurde.

Obwohl OCSP zunächst als effektive Lösung erschien, hat das neue Protokoll leider einige praktische Probleme in Bezug auf Leistung, Sicherheit und Datenschutz.

Performance-Probleme

Wenn Sie für jedes Zertifikat, auf das der Browser stößt, einen Responder kontaktieren, müssen Browser für jede neue HTTPS-Verbindung eine zusätzliche HTTP-Anforderung ausführen. Dieser Netzwerk-Overhead war für Benutzer spürbar, insbesondere auf Seiten mit Inhalten von Drittanbietern, die auf Remote-Servern zur Verteilung von Inhalten gespeichert sind (auf denen möglicherweise jeweils ein oder mehrere Zertifikate vorhanden sind).

Reaktionsfähigkeit ist ein wesentliches Prinzip für ein gutes Design der Benutzeroberfläche. Lange Verzögerungen können eine Hauptursache für die Frustration der Benutzer sein und dazu führen, dass Benutzer glauben, dass Ihre Website nicht funktioniert oder dass ihre Eingabegeste ignoriert wurde.

Was mehr ist, viele Studium In der Vergangenheit haben schnelle Seitenladegeschwindigkeit und Reaktionsfähigkeit mit verbesserter SEO und erhöhten Conversion-Raten verbunden. Tatsächlich hat Amazon berechnet, dass eine Verzögerung von nur einer Sekunde sie ungefähr kosten kann $ 1.6 Billion jährlich.

(Weitere Informationen darüber, wie sich die Geschwindigkeit beim Laden von Seiten auf Ihre Website auswirkt, und Vorschläge für Optimierungen finden Sie in unserer Artikel Beschreiben, wie das Entfernen gemischter Inhalte von Ihrer Website die Leistung verbessert.)

Sicherheitsfragen

Es gibt auch wichtige Sicherheitsbedenken bei OCSP. Die Tatsache, dass die meisten praktischen OCSP-Implementierungen nicht zuverlässig genug waren (entweder aufgrund von Netzwerkverzögerungen oder Konfigurations- oder Anwendungsfehlern), motivierte Browser und andere Client-Software, das Einchecken von OCSP zu implementieren Soft-Fail Modus arbeiten können.

Dies bedeutet, dass Browser dies tun, wenn ein OCSP-Server während der Antwort nicht erreicht werden kann oder eine Zeitüberschreitung auftritt Betrachten Sie das Zertifikat als gültig und fahren Sie trotzdem mit der HTTPS-Verbindung fort.

Der Grund dafür ist, dass ein OCSP-Server möglicherweise Millionen von Websites bedienen kann und ein OCSP-Server jederzeit ausfallen kann. Wenn die Verbindung bei jedem OCSP-Fehler unterbrochen wird, würde dies das Surferlebnis von Millionen von Benutzern stören. Selbst wenn der OCSP-Server in Betrieb ist, die Antwort jedoch lange dauert, erhöht dies die wahrgenommene Verzögerung und die Frustration der Benutzer.

Man-in-the-Middle (MITM) Es ist bekannt, dass Angreifer dieses Verhalten durch Blockieren ausnutzen Alle Verbindungen zu OCSP-Respondern, was effektiv bedeutet, dass sie ein gestohlenes Zertifikat- und Schlüsselpaar für eine schädliche Site verwenden können, unabhängig vom Sperrstatus des Zertifikats.

Datenschutzprobleme

Da ein Zertifikat mit einem Schlüssel und einem Domänennamen verknüpft ist und Browser vor jeder neuen HTTPS-Verbindung den Sperrstatus anfordern, bedeutet dies, dass Browser einen erheblichen Teil des Webprotokolls ihrer Benutzer an OCSP-Responder weitergeben.

Öffentlich vertrauenswürdige Zertifizierungsstellen sind natürlich keine böswilligen Organisationen, die die Privatsphäre der Benutzer gefährden möchten. (Seriöse Zertifizierungsstellen versuchen dies immer aktiv schützend Sicherheit und Datenschutz ihrer Benutzer.) Im Falle einer Gefährdung des OCSP-Responders einer Zertifizierungsstelle können Daten, die mit diesem nicht vertrauenswürdigen Server ausgetauscht werden, jedoch zur Offenlegung vertraulicher und privater Informationen führen.

OCSP Heften zur Rettung

Um diese Probleme zu beheben, haben Browser und Zertifizierungsstellen eine neue Methode zum Ermitteln des Status eines Zertifikats entwickelt: OCSP-Heften. Durch OCSP-Heften können Webserver (anstelle von Browsern) signierte OCSP-Antworten für ihre Zertifikate erhalten, die bis zu 7 Tage zwischengespeichert werden können.

Zu den Servern gehören (oder Klammer) die zwischengespeicherte OCSP-Antwort in ihren HTTPS-Antworten neben dem SSL-Zertifikat selbst. Auf diese Weise können Browser die CAs-Signatur in der OCSP-Antwort überprüfen und sicherstellen, dass das Zertifikat nicht widerrufen wurde, bevor die sichere Verbindung hergestellt wurde, ohne die teure zusätzliche Anforderung an den OCSP-Server selbst ausführen zu müssen.

OCSP-Heften ist eine einfache, aber sehr effektive Lösung für die oben genannten Probleme. Server können die zwischengespeicherten OCSP-Antworten in ihrer eigenen Zeit abrufen, wodurch der durch CRLs und OCSP verursachte Leistungsaufwand sowie die damit verbundenen Datenschutzbedenken beseitigt werden.

Das OCSP-Heften allein löst jedoch das Soft-Fail-Sicherheitsproblem von OCSP nicht vollständig. Da das Heften auf dem Server implementiert ist, können Browser nicht wissen, ob ein Server das Heften tatsächlich unterstützt oder nicht.

Infolgedessen können MITM-Angreifer mit einem gestohlenen (aber widerrufenen) Zertifikat einen Downgrade-Angriff ausführen, indem sie das Zertifikat ohne OCSP-Heftung bereitstellen. Der Browser eines Opfers kann nicht bestätigen, ob der Server das Heften tatsächlich unterstützt, und den OCSP-Responder wie gewohnt abfragen.

MITM-Angreifer können diese OCSP-Abfrage dann einfach blockieren und Browser effektiv dazu zwingen, das Zertifikat als gültig zu akzeptieren.

OCSP Must-Staple

Dieser Angriff motivierte Zertifizierungsstellen und Browserhersteller, eine Erweiterung für SSL-Zertifikate einzuführen, die in definiert ist RFC 7633, allgemein genannt OCSP Must-Staple (Obwohl der RFC selbst diesen Namen nicht erwähnt, was zu Verwirrung führen kann.) Dies erfordert lediglich das OCSP-Heften für das Zertifikat. Wenn ein Browser auf ein Zertifikat mit dieser Erweiterung stößt, das ohne OCSP-Heftung verwendet wird, wird es abgelehnt. OCSP Must-Staple mildert den oben genannten Downgrade-Angriff und reduziert unnötigen Datenverkehr zu den OCSP-Respondern der Zertifizierungsstelle, was auch zur Verbesserung der OCSP-Gesamtleistung beitragen kann.

Wenn Sie die OCSP Must-Staple-Erweiterung in Ihren Zertifikaten aktivieren möchten, wenden Sie sich an einen unserer Support-Mitarbeiter unter support@ssl.com für weitere Informationen.

Aktivieren Sie OCSP Stapling auf Ihrem Server

In den folgenden Abschnitten finden Sie Anweisungen zum Aktivieren der OCSP-Heftung in Ihrem Computer Apache . Nginx Umgebungen:

Apache

So aktivieren Sie das OCSP-Heften in Ihrem Apache Server, fügen Sie bitte die folgenden Zeilen in die Konfigurationsdatei Ihres Servers ein.

# OCSP-Heftung, nur in httpd 2.3.3 und höher SSLUseStapling auf SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderErrors aus SSLStaplingCache shmcb: / var / run / ocsp (128000)

Nginx

So aktivieren Sie das OCSP-Heften in Ihrem Nginx Server, fügen Sie bitte den folgenden Text in die Konfigurationsdatei Ihres Servers ein.

# OCSP Stapling --- # OCSP-Datensätze von der URL in ssl_certificate abrufen und zwischenspeichern ssl_stapling on; ssl_stapling_verify on;

Fazit

Das Web ist ein kompliziertes Netzwerk von voneinander abhängigen Komponenten, die (normalerweise) harmonisch zusammenarbeiten, um ein nahtloses Surferlebnis zu bieten. Die ständig zunehmende Komplexität dieses Systems schafft jedoch eine immer größer werdende Angriffsfläche und ermöglicht die Entwicklung und Ausführung neuer Netzwerkangriffe.

Die schiere Anzahl der Komponenten erhöht natürlich die Latenz und führt zu Verzögerungen. Dies bedeutet, dass Unternehmen Wege finden müssen, um die Sicherheit zu verbessern, ohne die Benutzererfahrung zu beeinträchtigen. Durch Aktivieren der OCSP-Heftung erhalten Sie die seltene Gelegenheit, die Sicherheit zu verbessern . Leistung für Ihre Website zur gleichen Zeit.

Wie immer beantworten wir gerne Ihre Fragen zu OCSP-Heftungen oder anderen Problemen. Schreiben Sie uns einfach eine E-Mail an support@ssl.com.

Verwandte Artikel

Abonnieren Sie den Newsletter von SSL.com

Was ist SSL /TLS?

Video abspielen

Abonnieren Sie den Newsletter von SSL.com

Verpassen Sie keine neuen Artikel und Updates von SSL.com