Wie Java 6, die SSL-Verbindung mit "SSL-Peer falsch heruntergefahren" fehlschlägt, wie Java 7 erfolgreich?

ich eine SSL-Verbindung von einem Client zu sehen, die Ausführung von Java 6 mit einer Ausnahme fehlschlagen wie:Wie Java 6, die SSL-Verbindung mit "SSL-Peer falsch heruntergefahren" fehlschlägt, wie Java 7 erfolgreich?

Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:882) 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1188) 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1215) 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1199) 
    at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434) 
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166) 
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:133) 
    ... 35 more 
Caused by: java.io.EOFException: SSL peer shut down incorrectly 
    at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:462) 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:863) 
    ... 41 more

Der Server ist eine Tomcat 7-basierte Anwendung, auf Java 7 ausgeführt, Linux und auf Amazon EC2, für das, was das wert ist.

Ich habe eine Menge Vorschläge zu möglichen Fällen gefunden, einschließlich der Verbindung versehentlich mit einem nicht-SSL-Port usw. Ich glaube, ich habe alles ausgeschlossen, vor allem, weil die genau gleichen Client funktioniert, wenn Java 7 ausgeführt wird ohne Veränderung. (OS X in beiden Fällen.)

Unten schließe ich die Debug-Ausgabe von Java 6 und Java 7 SSL-Verbindungsprozedur. Meine Frage an Experten lautet: schlägt dies vor, dass einige mögliche Verschlüsselungs- oder Protokolleinstellungen, vielleicht ein Standard in Java 7, in Java 6 aktiviert werden könnten, damit es funktioniert?

Java 6:

Allow unsafe renegotiation: false 
Allow legacy hello messages: true 
Is initial handshake: true 
Is secure renegotiation: false 
%% No cached client session 
*** ClientHello, TLSv1 
RandomCookie: GMT: 1363993281 bytes = { 77, 153, 100, 72, 45, 178, 253, 243, 195, 167, 17, 151, 39, 247, 148, 102, 213, 129, 39, 17, 26, 139, 157, 154, 63, 88, 41, 160 } 
Session ID: {} 
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV] 
Compression Methods: { 0 } 
*** 
main, WRITE: TLSv1 Handshake, length = 81 
main, WRITE: SSLv2 client hello message, length = 110 
main, received EOFException: error 
main, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake 
main, SEND TLSv1 ALERT: fatal, description = handshake_failure 
main, WRITE: TLSv1 Alert, length = 2 
main, called closeSocket()

Java 7:

Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 
Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA 
Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA 
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 
Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA 
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 
Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA 
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 
Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA 
Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA 
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256 
Allow unsafe renegotiation: false 
Allow legacy hello messages: true 
Is initial handshake: true 
Is secure renegotiation: false 
main, setSoTimeout(0) called 
%% No cached client session 
*** ClientHello, TLSv1 
RandomCookie: GMT: 1363993435 bytes = { 131, 83, 80, 186, 215, 90, 171, 131, 231, 18, 184, 183, 249, 155, 197, 204, 73, 1, 74, 79, 32, 142, 236, 28, 111, 37, 58, 255 } 
Session ID: {} 
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV] 
Compression Methods: { 0 } 
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1} 
Extension ec_point_formats, formats: [uncompressed] 
Extension server_name, server_name: [host_name: ec2-xx-xx-xx-xx.compute-1.amazonaws.com]

Quelle

2013-03-23 Sean Owen

Ist der Fehler sichtbar von dem Client? Ich habe diese Art von Fehlern zuvor im Rahmen der normalen SSL-Verhandlung gesehen, d. H. Sie hat aus der Sicht des Benutzers "funktioniert". – Taylor

Mit Java 6 greift der Client hello auf SSLv2 zurück, während er mit Java 7 mit TLSv1 ausgeführt wird. Ich glaube, dass JSSE unter Java 6 SSL V2 nicht offiziell unterstützt, aber ich muss das forschen –

Mit 'openssl s_client -connect Servername: 443' können Sie debuggen welches Protokoll der Server unterstützt und Tests durchführen, indem Sie Flags wie' ssl2', 'erzwingen ssl2', überprüfen [this] (http://www.openssl.org/docs/apps/s_client.html) –

Brunos Antwort war am Ende die richtige. Dies wird am einfachsten durch die Systemeigenschaft https.protocols gesteuert. Auf diese Weise können Sie steuern, was die Factory-Methode zurückgibt. Stellen Sie beispielsweise "TLSv1" ein.

Quelle

2013-03-31 16:08:05

Es führt zu Problemen, wenn Sie zwei Protokolle anstelle von einem verwenden möchten. Zum Beispiel 'SSLv3' und' TLSv1'. Diese '-Dhttps.protocols = TLSv1, SSLv3' führt zu Ausnahmen, wenn Sie versuchen, entweder SSLv3 oder TLSv1 zu verbinden. – Dragon

@Dragon Wirklich? Welche Ausnahmen? Warum? – EJP

Es scheint, dass in dem Debug-Protokoll für Java 6 die Anforderung in SSLv2 Format senden.

Haupt, WRITE: SSLv2 Client hallo Nachricht, Länge = 110

Dies ist nicht als standardmäßig in Java 7.
Ändern Sie den Client verwenden SSLv3 und über die Interoperabilität zu vermeiden aktiviert erwähnt wird Probleme.

Blick für Unterschiede in JSSE Anbieter in Java 7 und Java 6

Quelle

2013-03-23 18:05:50 Cratylus

Ja das sind gute Beweise und in der Tat scheint das SSLv2 das Problem zu sein. Diese Art von führt zu meiner Antwort hier, obwohl @EJP richtig ist, dass es am besten wäre, einen Weg zu finden, SSLv2 explizit auszuschalten. –

Remove "SSLv2ClientHello" von den aktivierten Protokolle auf dem Client SSLSocket oder HttpsURLConnection.

Quelle

2013-03-23 23:48:55 EJP

Ich denke, das ist genau richtig, obwohl ich nicht sicher bin, wie es geht. Ich baue eine 'SSLSocketFactory' für die Plattform. 'SSLContext.createSSLEngine()' erstellt eine 'SSLEngine' mit Methoden, um Protokolle zu setzen (nicht zu entfernen, scheint es). Aber ich glaube nicht, dass dies der 'SSLSocketFactory' hilft. Der 'SSLContext' erlaubt Ihnen auch nur nach einem Protokoll zu fragen und nicht die anderen zu deaktivieren, die damit verbunden sind (?). Wenn Sie wissen, wie das geht, lassen Sie es mich wissen. –

Rufen Sie die aktivierten Protokolle ab, entfernen Sie "SSLv2ClientHello" und legen Sie sie auf den verbleibenden Wert fest. – EJP

Ich glaube nicht, dass es eine solche Methode gibt. Zumindest kann ich es nicht auf 'SSLContext' oder' SSLSocketFactory' sehen. 'SSLEngine' ist nicht hilfreich, glaube ich, da das Framework später sein eigenes wird. Wir werden weiter suchen. –

Machen Sie es wie folgt aus:

SSLSocket socket = (SSLSocket) sslFactory.createSocket(host, port); 
socket.setEnabledProtocols(new String[]{"SSLv3", "TLSv1"});

Quelle

2013-12-27 10:18:53

Aktualisierung der Server Argumente von -Dhttps.protocols = SSLv3 zu -Dhttps.protocols = TLSv1, SSLv3

Quelle

2015-01-05 21:54:40 Alekya

Wie Java 6, die SSL-Verbindung mit "SSL-Peer falsch heruntergefahren" fehlschlägt, wie Java 7 erfolgreich?

Antwort

Verwandte Themen