it-swarm.com.de

Was bedeutet "javax.net.ssl.SSLHandshakeException: Serverzertifikatsänderung schränkt die Neuaushandlung ein" und wie kann dies verhindert werden?

Wir verwenden Oracle jdk 1.7.0_71 und Tomcat 7.0.55 ..__ Leider haben wir bei SSL-Verbindungen zwischen Servern die folgende Ausnahme erhalten:

javax.net.ssl.SSLHandshakeException: server certificate change is restrictedduring renegotiation

Was bedeutet es? Wie kann man das verhindern?

Die Ausnahme ist nach dem Neustart von Tomcat nicht mehr vorhanden.

Der volle Stapel:

Caused by: javax.net.ssl.SSLHandshakeException: server certificate change is restrictedduring renegotiation
        at Sun.security.ssl.Alerts.getSSLException(Alerts.Java:192) ~[?:1.7.0_71]
        at Sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.Java:1884) ~[?:1.7.0_71]
        at Sun.security.ssl.Handshaker.fatalSE(Handshaker.Java:276) ~[?:1.7.0_71]
        at Sun.security.ssl.Handshaker.fatalSE(Handshaker.Java:266) ~[?:1.7.0_71]
        at Sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.Java:1402) ~[?:1.7.0_71]
        at Sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.Java:209) ~[?:1.7.0_71]
        at Sun.security.ssl.Handshaker.processLoop(Handshaker.Java:878) ~[?:1.7.0_71]
        at Sun.security.ssl.Handshaker.process_record(Handshaker.Java:814) ~[?:1.7.0_71]
        at Sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.Java:1016) ~[?:1.7.0_71]
        at Sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.Java:1312) ~[?:1.7.0_71]
        at Sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.Java:702) ~[?:1.7.0_71]
        at Sun.security.ssl.AppOutputStream.write(AppOutputStream.Java:122) ~[?:1.7.0_71]
        at Java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.Java:82) ~[?:1.7.0_71]
        at Java.io.BufferedOutputStream.flush(BufferedOutputStream.Java:140) ~[?:1.7.0_71]
        at org.Apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.Java:506) ~[commons-httpclient-3.1.jar:?]
        at org.Apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.Java:2114) ~[commons-httpclient-3.1.jar:?]
        at org.Apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.Java:1096) ~[commons-httpclient-3.1.jar:?]
        at org.Apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.Java:398) ~[commons-httpclient-3.1.jar:?]
        at org.Apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.Java:171) ~[commons-httpclient-3.1.jar:?]
        at org.Apache.commons.httpclient.HttpClient.executeMethod(HttpClient.Java:397) ~[commons-httpclient-3.1.jar:?]
        at org.Apache.commons.httpclient.HttpClient.executeMethod(HttpClient.Java:323) ~[commons-httpclient-3.1.jar:?]
        at org.springframework.remoting.httpinvoker.CommonsHttpInvokerRequestExecutor.executePostMethod(CommonsHttpInvokerRequestExecutor.Java:205) ~[spring-web-3.2.9.RELEASE.jar:3.2.9.RELEASE]
        at org.springframework.remoting.httpinvoker.CommonsHttpInvokerRequestExecutor.doExecuteRequest(CommonsHttpInvokerRequestExecutor.Java:140) ~[spring-web-3.2.9.RELEASE.jar:3.2.9.RELEASE]
        at org.springframework.remoting.httpinvoker.AbstractHttpInvokerRequestExecutor.executeRequest(AbstractHttpInvokerRequestExecutor.Java:136) ~[spring-web-3.2.9.RELEASE.jar:3.2.9.RELEASE]
        at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.executeRequest(HttpInvokerClientInterceptor.Java:192) ~[spring-web-3.2.9.RELEASE.jar:3.2.9.RELEASE]
        at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.executeRequest(HttpInvokerClientInterceptor.Java:174) ~[spring-web-3.2.9.RELEASE.jar:3.2.9.RELEASE]
        at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.invoke(HttpInvokerClientInterceptor.Java:142) ~[spring-web-3.2.9.RELEASE.jar:3.2.9.RELEASE]
        ... 160 more
40
Michael

Diese Fehlermeldung im Client-Layer-Code ist eine Folge von Code-Hardening nach "SSL V3.0 Poodle-Sicherheitsanfälligkeit - CVE-2014-3566" in kürzlich durchgeführten Java-Updates. Und es ist ein Fehler - hier sind Umgehungsmöglichkeiten, falls Sie Ihre JRE nicht sofort aktualisieren können:

Eine erste Option besteht im Erzwingen des TLS-Protokolls beim Aufbau einer HTTPS-Verbindung:

Wenn Sie HttpClient auf eine aktuellere Version als 4.3.6 aktualisieren können, wird SSLv3 standardmäßig deaktiviert, und Ihr Code sollte eine solche Ausnahme nicht mehr melden.

Wenn Sie Ihre HttpClient-Version nicht aktualisieren können, müssen Sie den Code dieser Antwort verwenden, um Protokolle auf TLS zu beschränken: https://stackoverflow.com/a/26439487/737790

Für andere HTTP-Zugriffe von Java 7-Laufzeit aus muss die folgende Systemeigenschaft festgelegt werden

-Dhttps.protocols="TLSv1"

Ausführliche Informationen finden Sie hier: Java-HTTP-Clients und POODLE


Eine zweite Option besteht darin, die Clientüberprüfung zu lockern, um weiterhin eine Neuaushandlung mit den folgenden Eigenschaften zu ermöglichen:

-Djdk.tls.allowUnsafeServerCertChange=true 
-Dsun.security.ssl.allowUnsafeRenegotiation=true


Eine dritte Option besteht darin, Ihre Serverzertifikate so zu "verbessern", dass alle IP-Adressen Ihrer Cluster-Mitglieder als alternative Antragstellernamen gemäß diesem Beitrag im Burp-Forum enthalten sind.


Eine vierte Option ist das Downgrade Ihrer Java-Version, bevor diese Zertifikat-/Neuverhandlungsprüfungen hinzugefügt wurden, also vor 7u41 (zur Bestätigung).

Updates Dieses fehlerhafte Verhalten wurde in den JDK-Updates 7u85 und 8u60 behoben. Dank an Pada, dass Sie die Referenz " JDK-8072385 " gefunden haben.

46
Yves Martin

Das folgende Code-Stück hat in einer Unternehmensumgebung unter folgenden Bedingungen für uns gearbeitet:

  • ein nahtloses (Laufzeit-) Zertifikat-Update ist eine wichtige Voraussetzung
  • es ist zu teuer, den in der Anwendung verwendeten HTTPClient zu aktualisieren
  • das Beschränken des https-Protokolls auf "TLSv1" hat keine Wirkung
  • die Anwendung ist ein JNLP-gestützter Java-Client, und die Berechtigungen "allowUnsafeServerCertChange" und "allowUnsafeRenegotiation" dürfen nicht über JNLP-Argumente an die Clientanwendung übergeben werden.
  • das Setzen von "allowUnsafeServerCertChange" und "allowUnsafeRenegotiation" über System.setProperty () - Aufrufe während des Bootstraps der Anwendung hat keine Auswirkungen.

    if (e.getCause() instanceof SSLHandshakeException) {
        logger.debug("server https certificate has been altered");
        try {
            Class<?> c = Class.forName("Sun.security.ssl.ClientHandshaker");
            Field allowUnsafeServerCertChangeField = c.getDeclaredField("allowUnsafeServerCertChange");
            allowUnsafeServerCertChangeField.setAccessible(true);
            Field modifiersField = Field.class.getDeclaredField("modifiers");
            modifiersField.setAccessible(true);
            modifiersField.setInt(allowUnsafeServerCertChangeField, allowUnsafeServerCertChangeField.getModifiers() & ~Modifier.FINAL);
            allowUnsafeServerCertChangeField.set(null, true);
            logger.debug("client has been updated in order to support SSL certificate change (re-negotiation) on runtime.");
        }
        catch (Exception ex) {
            logger.debug("client cannot be updated to support SSL certificate change (re-negotiation) on runtime. Please restart the application.", ex);
        }
    }
    

Bitte beachten Sie, dass dies als Hack (Einführen einer Sicherheitsanfälligkeit) betrachtet werden sollte und in einer vertrauenswürdigen Umgebung verwendet werden sollte. Bevor Sie diesen Weg gehen, sollten Sie alle Optionen in Yves Antwort ausprobieren.

5
Mert Z.

Dies kann auch auf falsch konfigurierte Konnektivität zurückzuführen sein, z. B. ein Haproxy mit einem oder mehreren Lastausgleichszielen, die auf die falsche IP-Adresse verweisen, sodass X Prozent der Anforderungen ein anderes Zertifikat erhalten.

2
nbryant

Ich habe dieses Problem erhalten, weil die Serverseite ihre Zertifikate aktualisiert hat. Zuvor funktionierte unser Kunde gut. Wir haben unser Programm einfach neu gestartet und es hat sich wieder normalisiert.

1
Charlie

Ich hatte dieses Problem und es stellte sich heraus, dass der Client den Dienst mit einem anderen Zertifikat hinter einem Load Balancer anrief. 

0
John