Zwischenspeichern Webbrowser SSL-Zertifikate?

26

Zwischenspeichern Webbrowser SSL-Serverzertifikate? Wenn ich zum Beispiel das SSL-Zertifikat auf einem Webserver ändere, können alle Webbrowser das neue Zertifikat abrufen, wenn sie eine Verbindung über SSL herstellen, oder ist es möglich, dass sie ein veraltetes Zertifikat haben?

Ich denke an das Szenario, in dem ein SSL-Zertifikat abläuft und auf dem Webserver durch ein neues ersetzt wird.

— Lorin Hochstein
quelle

Ich gehe davon aus, dass der Browser das Datum auf dem Zertifikat überprüft, um festzustellen, ob er ein neues Datum benötigt.

— Soandos

Schauen Sie sich hier imperialviolet.org/2011/05/04/pinning.html über "Certificate Pinning" und die HSTS-Initiative an, die mit der früheren dev.chromium.org/sts

— Shadok

1

Ab 2019 speichert mein Chrome 75 SSL-Zertifikate zwischen

— Fabian Thommen,

10

Nun, die Antwort von RedGrittyBrick ist richtig, aber sie beantwortet die Frage nicht wirklich. Die Frage war, ob Browser dies tun und nicht, ob sie es tun sollten oder müssen.

Soweit ich gehört habe, führen sowohl MSIE als auch Chrome Cache-Zertifikate aus und ersetzen sie nicht, wenn sie eine neue Version erhalten, solange die alte gültig ist. Warum sie dies tun, ist für mich nicht nachvollziehbar, da es die Sicherheit senkt.

— tuexss
quelle

Die aktuell akzeptierte Antwort ist ziemlich klar. Es zeigt insbesondere , dass, keine , Browser die Zertifikate nicht zwischenspeichern. Wenn Sie darauf hinweisen, dass sich die Landschaft geändert hat, und die Gründe, die Chrome hat, gut dokumentiert sind, wäre es schön, wenn Sie einen Link zu diesen Gründen erstellen würden. Da das Zertifikat immer noch gültig ist, wird die Sicherheit, die keinen Sinn ergibt, nicht "herabgesetzt".

— Ramhound

3

Es senkt es, weil Sie einen alten SHA-1-Schlüssel nicht durch einen neueren ersetzen können, weil der alte noch gültig ist und Chrome den neuen ignoriert, wenn ich alles richtig verstanden habe. Es gibt also keine Möglichkeit, einen Wechsel zu einem höheren Sicherheitsstandard zu erzwingen - er "senkt" sich also in einem relativen Sinne, indem er nicht aktiviert wird, ihn höher zu drücken. So wie die Inflation nicht den festgelegten Geldwert senkt, sondern den tatsächlichen Marktwert.

— Dienstag,

5

+1 Nach dem Fiasko der StartSSL-gemischten SHA1 / SHA2-Kette ist klar, dass Chrome unter Windows in der Tat Zwischenzertifikate zwischenspeichert, möglicherweise auf unbestimmte Zeit. Chrome ignoriert alle neuen Zwischenzertifikate, die vom Server gesendet werden. Es ist jedoch nicht klar, ob das Caching durch die Identität des Serverzertifikats oder des Zwischenzertifikats verschlüsselt ist und was genau diese Identität ausmacht.

— Robert Važan

3

Das Problem tritt heute auf. Sowohl Chrome als auch Firefox zeigen im normalen Fenster (altes Zertifikat) und im Inkognito-Modus (korrektes Zertifikat) unterschiedliche Zertifikate an. Befehlszeilenprogramme wie curl oder openssl melden natürlich das korrekte Zertifikat. Behoben durch Löschen des Browser-Cache (Strg + Umschalt + Entf) - "Cookies und andere Site-Daten" für Chrome und "Offline-Website-Daten" für Firefox.

— Anilech

1

Zumindest die aktuelle Version von Firefox (66.0) unter OSX scheint ziemlich stark am Cache festzuhalten. Gestern habe ich ein TLS-Zertifikat für meine Website aktualisiert und sowohl CLI opensslals auch Chromium zeigen mir das neue Zertifikat. Firefox zeigt mir den alten trotz des Nachladens mit deaktiviertem Cache, löscht alle Cache- und Offlinedaten und führt einen Neustart des Browsers durch.

— Tad Lispy

20

Siehe IBM SSL-Übersicht

Der SSL-Client sendet eine "Client-Hallo" -Nachricht, in der kryptografische Informationen wie die SSL-Version und, in der vom Client bevorzugten Reihenfolge, die vom Client unterstützten CipherSuites aufgelistet sind. Die Nachricht enthält auch eine Zufallsbytezeichenfolge, die in nachfolgenden Berechnungen verwendet wird. Das SSL-Protokoll ermöglicht es dem "Client Hallo", die vom Client unterstützten Datenkomprimierungsmethoden einzuschließen, aktuelle SSL-Implementierungen enthalten diese Bestimmung jedoch normalerweise nicht.

Der SSL-Server antwortet mit einer "Server-Hallo" -Nachricht, die die vom Server ausgewählte CipherSuite aus der vom SSL-Client bereitgestellten Liste, die Sitzungs-ID und eine weitere zufällige Byte-Zeichenfolge enthält. Der SSL-Server sendet auch sein digitales Zertifikat . Wenn der Server ein digitales Zertifikat für die Clientauthentifizierung benötigt, sendet der Server eine "Clientzertifikatsanforderung", die eine Liste der unterstützten Zertifikatstypen und die Distinguished Names akzeptabler Zertifizierungsstellen (CAs) enthält.

Der SSL-Client überprüft die digitale Signatur auf dem digitalen Zertifikat des SSL-Servers und prüft, ob die vom Server ausgewählte CipherSuite akzeptabel ist.

…

Die Zusammenfassung von Microsoft ist ähnlich. Auch der TLS-Handshake ist in dieser Hinsicht ähnlich.

In Schritt 2 scheint es für den Client keine Möglichkeit zu geben, zu sagen, dass er kein Serverzertifikat senden soll, sondern meinen Cache verwenden soll.

Beachten Sie, dass es verschiedene Arten von Zertifikaten gibt: Client, Server und Zertifizierungsstelle. Einige davon werden zwischengespeichert.

— RedGrittyBrick
quelle

Die ursprüngliche Frage wurde geändert, um zu verdeutlichen, dass es sich um ein Serverzertifikat handelt.

— Lorin Hochstein

Dies ist nicht der Fall, und die Annahme, dass es keinen Cache gibt, da ein Überblick über die Funktionsweise von SSL das Zwischenspeichern ausschließt, ist eine ziemlich schlechte Rechtfertigung. youtube.com/watch?v=wMFPe-DwULM

— Evan Carroll

Der einzige Cache, der verwendet werden könnte, ist für Gültigkeitsprüfungen, obwohl dies eine Sicherheitslücke darstellt.

— Daniel B

0

Ich bin mir nicht sicher, ob meine Eingabe in irgendeiner Weise hilfreich sein wird. Ich habe jedoch Folgendes erfahren: Ich habe eine Website in Azure mit einer benutzerdefinierten Domain. Ich habe versucht, mit https in Chromes darauf zuzugreifen, bevor ich die SSL-Bindung für meinen Domainnamen konfiguriert habe. Chrome hat mir mitgeteilt, dass die Site nicht gesichert ist, was durchaus Sinn macht (ERR_CERT_COMMON_NAME_INVALID). Nachdem ich mein Zertifikat hochgeladen und die SSL-Bindung in Azure konfiguriert habe, wurde jedoch immer noch derselbe Fehler angezeigt. Zu diesem Zeitpunkt funktionierte https beim Öffnen eines neuen privaten Browserfensters (oder bei Verwendung eines anderen Browsers) einwandfrei.

In meiner offenen Chrome-Sitzung konnte ich es jedoch nie zum Laufen bringen. Ich habe versucht, den SSL-Status zu löschen, das gleiche Ergebnis. Es funktionierte nach dem Neustart von Chrome insgesamt.

Ich wurde wahrscheinlich von etwas ausgetrickst, aber es sah fast so aus, als wäre das Zertifikat zwischengespeichert worden ...

— Etienne
quelle

Dieser Fehler würde bedeuten, dass Sie auf die Site mit einem URI zugegriffen haben, der sich von dem im CN unterschied. Haben Sie den URI geändert, um auf die Website in Chrome zuzugreifen, nachdem Sie die Bindung eingerichtet haben?

— Seth

Nein, das einzige, was ich damals geändert habe, war die Bindung. Als ich https zum ersten Mal abgefragt habe, wurde es mit dem standardmäßigen Azure SSL-Zertifikat bereitgestellt, aber es hat mir dieses weiterhin bereitgestellt, nachdem ich die Bindung mit dem richtigen Zertifikat in Azure geändert habe.

— Etienne

Bedeutet das, dass Sie, wie Sie sagten, Ihre Domain-SSL-Bindung konfiguriert haben, dass Sie mit Ihrer Domain von Anfang an auf den Server zugegriffen haben oder nicht? Der Fehler weist darauf hin, dass ein Unterschied zwischen der von Ihnen verwendeten URL und der URL besteht, für die das Zertifikat erstellt wurde. Das ist es was ich meinte. Außerdem kann Ihre tatsächliche Serverkonfiguration von großer Bedeutung sein, wenn Sie an HSTS und dergleichen denken.

— Seth

1

Schritt 1: Veröffentlichte Website in Azure. Zu diesem Zeitpunkt verfügt es sowohl über eine Azure-Standard-URL als auch über ein Standardzertifikat. Schritt 2: Richten Sie eine benutzerdefinierte Domain für die Web-App ein. Jetzt verweist mysite.com korrekt auf die Site. Das SSL-Zertifikat für mysite.com ist derzeit nicht konfiguriert. Schritt 3: An diesem Punkt, wenn ich versuche, die Site mit https zu versehen, erhalte ich einen Sicherheitsfehler, der besagt, dass das Zertifikat nicht übereinstimmt (und es ist absolut sinnvoll). Schritt 4: Ich installiere das SSL-Zertifikat für Mysite.com in Azure und STILL Die Sicherheitswarnung wird von Chrome angezeigt. Es tritt in keinem anderen Browser auf oder wenn ich eine private Navigation öffne.

— Etienne

1

Schritt 5: Ich starte Chrome neu und jetzt (und erst jetzt) wird meine Website mit dem richtigen SSL-Zertifikat bereitgestellt. Daher ist meine Schlussfolgerung, dass es tatsächlich eine Caching-Ausgabe des Zertifikats gab

— Etienne,

-1

Es gibt Pläne einiger Browser-Entwickler, ein solches Chaching-System zur Erkennung von Angriffen wie dem Angriff auf Diginotar 2011 zu implementieren .

Derzeit ist in den aktuellen Browsern kein solches AFAIK-System aktiv. Daher müssen Sie beim Aktualisieren Ihres Serverzertifikats nicht über diese Situation nachdenken.

— Robert
quelle