Wir betreiben eine Web-Anwendung mit einem JVM-Backend (Java 7 Update 75; Code ist in Scala, aber ich glaube nicht, dass das relevant ist). Wir verwenden Google zur Authentifizierung über Oauth.
In den letzten Monaten gab es eine Handvoll Tage, an denen wir die Benutzer nicht zeitweise authentifizieren konnten.
Die Weiterleitung von und zu Google ist erfolgreich, aber wenn wir versuchen, token_endpoint unter Ссылка aufzurufen Zur Validierung der Authentifizierung erhalten wir manchmal die folgende Ausnahme: javax.net.ssl.SSLHandshakeException: server certificate change is restrictedduring renegotiation .
Dieser Kommentar zu einer anderen Frage führte mich dazu, einen JDK-Bug zu finden, der sich als diese Ausnahme manifestieren kann ( Was bedeutet" javax.net.ssl.SSLHandshakeException: Änderung des Serverzertifikats ist bei Neuverhandlung eingeschränkt "und wie kann es verhindert werden? ).
Meine Arbeitshypothese ist:
Der Fehler ( Ссылка ) bedeutet, dass nur der erste Eintrag im Subject Alternative Name (SAN) Liste ist markiert. Die obige Ausnahme wird ausgelöst, wenn sich der zu überprüfende Hostname in der SAN-Liste befindet, jedoch nicht am Anfang der Liste.
Gestern (27. Mai 2015 von) haben wir zwei verschiedene Zertifikate gesehen, die zeitweise von www.googleapis.com serviert wurden. Die erste (serial 67:1a:d6:10:cd:1a:06:cc ) hatte eine SAN-Liste von DNS:*.googleapis.com, DNS:*.clients6.google.com, DNS:*.cloudendpointsapis.com, DNS:cloudendpointsapis.com, DNS:googleapis.com , während die zweite (serial 61:db:c8:52:b4:77:cf:78 ) eine SAN-Liste von: DNS:*.storage.googleapis.com, DNS:*.commondatastorage.googleapis.com, DNS:*.googleapis.com .
Aufgrund des Fehlers in der JVM können wir das erste Zertifikat validieren, aber die Ausnahme wird mit der zweiten ausgelöst (obwohl sie absolut gültig ist), da *.googleapis.com nicht der erste Eintrag in der SAN-Liste ist.
Der Fix ist in der noch zu veröffentlichenden 7u85 (keine Angabe, wann diese verfügbar sein wird).
Ich habe einen einzelnen Knoten unseres Clusters auf 7u65 heruntergestuft, aber das Zertifikat schien um die Zeit zurückgekehrt zu sein (der letzte Fehler, den wir gesehen haben, war 22: 20GMT), so dass es schwierig ist, eine Bestätigung festzuhalten.
Hat jemand anderes dies oder etwas ähnliches erfahren und eine andere Problemumgehung als das Downgrade (Herunterstufung entfernt verschiedene andere SSL / TLS-Prüfungen)?
Ich bin nicht wirklich sicher, dass Ihr Problem mit einem JVM-Fehler zusammenhängt.
Bei CVE-2014-6457, " Triple Handshake-Angriff gegen TLS / SSL-Verbindungen (JSSE, 8037066) ", gibt es einen Fix in Java 6 und höher, der verhindert, dass Peer-Zertifikate während der Neuverhandlung geändert werden.
Problem Erklärung:
Eine Sicherheitslücke in allen Versionen der Transportschicht Sicherheitsprotokoll (TLS) (einschließlich der älteren Secure Socket Layer) (SSLv3)) können Man-In-The-Middle-Angriffe (MITM) zulassen, wenn sie ausgewählt wurden Klartext wird als Präfix einer TLS-Verbindung injiziert. Dies Die Sicherheitslücke ermöglicht es einem Angreifer nicht, die Datei zu entschlüsseln oder zu modifizieren abgefangene Netzwerkkommunikation, sobald der Client und der Server erfolgreich eine Sitzung zwischen ihnen ausgehandelt.
Wenn das möglicherweise geänderte Zertifikat für dieselbe Identität wie das zuletzt gesehene Zertifikat gilt, ist die Verbindung jedoch zulässig.
Zwei Identitäten werden in diesem Fall als gleich angesehen:
Unter anderen Bedingungen (die Identität des Zertifikats hat sich geändert) wird eine javax.net.ssl.SSLHandshakeException: server certificate change is restricted during renegotiation Ausnahme ausgelöst.
Workaround:
-Djdk.tls.allowUnsafeServerCertChange=true deaktiviert den Schutz des unsicheren Serverzertifikats. Aktualisieren Sie auf jeden Fall Ihren Post mit Ihrem Google OAUTH-Client-Code, bevor Sie den Token_endpoint aufrufen, um die Authentifizierung zu überprüfen, um zu sehen, was passiert.
Tags und Links java jvm-hotspot google-authentication google-oauth ssl-certificate