Connexion SSL à défaut de Java 7

Je tente de créer une connexion SSL sur un serveur distant à l'aide de Java 7 et je suis la réception de l'exception suivante:

javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:946)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
    at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:702)
    at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122)
    at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
    at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
    at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
    at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
    at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
    at java.io.BufferedWriter.flush(BufferedWriter.java:254)
    at ssl7.Client.main(Client.java:22)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
    at sun.security.ssl.InputRecord.read(InputRecord.java:482)
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)

Lorsque j'exécute à nouveau le code à l'aide de la version 6 de Java, il n'y a pas d'exception. J'ai trouvé des références à ce problème ailleurs sur StackOverflow mais ma situation est livré avec une torsion. Le code du client, qui échoue avec Java 7 est

public class Client {

    public static void main(String[] args) throws FileNotFoundException, IOException, ClassNotFoundException {
        try {
            SSLSocketFactory sslsocketfactory = (SSLSocketFactory) SSLSocketFactory.getDefault();
            SSLSocket sslsocket = (SSLSocket) sslsocketfactory.createSocket("login.solon.com", 443);    
            OutputStream outputstream = sslsocket.getOutputStream();
            OutputStreamWriter outputstreamwriter = new OutputStreamWriter(outputstream);
            BufferedWriter bufferedwriter = new BufferedWriter(outputstreamwriter);
                bufferedwriter.write("hello\n");
                bufferedwriter.flush();
        } catch (Exception exception) {
            exception.printStackTrace();
        }
    }
}

Quand j'ai ajouter la ligne

sslsocket.setEnabledCipherSuites(new String[] {"SSL_RSA_WITH_RC4_128_MD5"});

après la création de la socket, il fonctionne.

maintenant, SSL_RSA_WITH_RC4_128_MD5 existe dans l'ensemble des suites de chiffrement donc, tout ce que j'ai fait est d'ajouter des restrictions. Restreindre les suites de chiffrement n'est pas une solution viable à long terme. Quelqu'un peut-il expliquer ce qui se passe ici?

L'intégralité du journal de débogage est:

keyStore is : 
keyStore type is : jks
keyStore provider is : 
init keystore
init keymanager of type SunX509
trustStore is: C:\Temp\keystore\clientkeystore
trustStore type is : jks
trustStore provider is : 
init truststore
adding as trusted cert:
Subject: CN=W, OU=D, O=S, L=H, ST=I, C=IL
Issuer:  CN=W, OU=D, O=S, L=H, ST=I, C=IL
Algorithm: DSA; Serial number: 0x4a6e05b7
Valid from Mon Oct 07 10:22:54 EEST 2013 until Sun Jan 05 09:22:54 EET 2014
adding as trusted cert:
Subject: CN=login.solon.com, OU=Domain Validated, OU=Thawte SSL123 certificate, OU=Go to https://www.thawte.com/repository/index.html
Issuer:  CN=Thawte DV SSL CA, OU=Domain Validated SSL, O="Thawte, Inc.", C=US
Algorithm: RSA; Serial number: 0x3012ec22473f20aa2cdc4bf7fe2d22f4
Valid from Wed Feb 13 02:00:00 EET 2013 until Thu Apr 14 02:59:59 EEST 2016
adding as trusted cert:
Subject: CN=W, OU=D, O=S, L=H, ST=I, C=IL
Issuer:  CN=W, OU=D, O=S, L=H, ST=I, C=IL
Algorithm: RSA; Serial number: 0x5864235a
Valid from Mon Oct 07 10:28:06 EEST 2013 until Sun Jan 05 09:28:06 EET 2014
trigger seeding of SecureRandom
done seeding SecureRandom
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: true
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
%% No cached client session
*** ClientHello, TLSv1
RandomCookie:  GMT: 1381093608 bytes = { 221, 239, 107, 239, 150, 213, 224, 210, 101, 229, 42, 58, 92, 9, 151, 0, 128, 105, 0, 55, 53, 224, 90, 111, 130, 175, 61, 121 }
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]
***
[write] MD5 and SHA1 hashes:  len = 149
0000: 01 00 00 91 03 01 52 52   D1 E8 DD EF 6B EF 96 D5  ......RR....k...
0010: E0 D2 65 E5 2A 3A 5C 09   97 00 80 69 00 37 35 E0  ..e.*:\....i.75.
0020: 5A 6F 82 AF 3D 79 00 00   2A C0 09 C0 13 00 2F C0  Zo..=y..*...../.
0030: 04 C0 0E 00 33 00 32 C0   07 C0 11 00 05 C0 02 C0  ....3.2.........
0040: 0C C0 08 C0 12 00 0A C0   03 C0 0D 00 16 00 13 00  ................
0050: 04 00 FF 01 00 00 3E 00   0A 00 34 00 32 00 17 00  ......>...4.2...
0060: 01 00 03 00 13 00 15 00   06 00 07 00 09 00 0A 00  ................
0070: 18 00 0B 00 0C 00 19 00   0D 00 0E 00 0F 00 10 00  ................
0080: 11 00 02 00 12 00 04 00   05 00 14 00 08 00 16 00  ................
0090: 0B 00 02 01 00                                     .....
main, WRITE: TLSv1 Handshake, length = 149
[Raw write]: length = 154
0000: 16 03 01 00 95 01 00 00   91 03 01 52 52 D1 E8 DD  ...........RR...
0010: EF 6B EF 96 D5 E0 D2 65   E5 2A 3A 5C 09 97 00 80  .k.....e.*:\....
0020: 69 00 37 35 E0 5A 6F 82   AF 3D 79 00 00 2A C0 09  i.75.Zo..=y..*..
0030: C0 13 00 2F C0 04 C0 0E   00 33 00 32 C0 07 C0 11  .../.....3.2....
0040: 00 05 C0 02 C0 0C C0 08   C0 12 00 0A C0 03 C0 0D  ................
0050: 00 16 00 13 00 04 00 FF   01 00 00 3E 00 0A 00 34  ...........>...4
0060: 00 32 00 17 00 01 00 03   00 13 00 15 00 06 00 07  .2..............
0070: 00 09 00 0A 00 18 00 0B   00 0C 00 19 00 0D 00 0E  ................
0080: 00 0F 00 10 00 11 00 02   00 12 00 04 00 05 00 14  ................
0090: 00 08 00 16 00 0B 00 02   01 00                    ..........
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
[Raw write]: length = 7
0000: 15 03 01 00 02 02 28                               ......(
main, called closeSocket()
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:946)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:702)
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
at java.io.BufferedWriter.flush(BufferedWriter.java:254)
at ssl7.Client.main(Client.java:22)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at sun.security.ssl.InputRecord.read(InputRecord.java:482)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)
... 10 more

Grâce.

Particulièrement bien mis en forme question! Keep it up!
Peut-être que votre code a besoin d'une ferme poignée de main. Je sais que je peux refuser toutes les connexions avec une poignée de main faible.
Laquelle certaines versions de java que vous utilisez? À la fois sur le client et le serveur.
J'ai couru le code Java 1.7.0_21 vs 1.6.0_25
Le serveur est en cours d'exécution 1.7.0_21
Sur quelle plate-forme est le serveur en cours d'exécution?

InformationsquelleAutor twizansk | 2013-10-07

java ssl

7

J'ai vu ce genre de problème lors de l'utilisation d'une Ubuntu 12.04 server exécutant un serveur basé sur Java à l'aide de son paquet OpenJDK. (Ceci peut avoir été corrigé depuis, que je ne suis pas en mesure de reproduire le problème avec les dernières mises à jour, mais ma configuration peut être légèrement différent, je ne me souviens pas.)

C'était essentiellement le problème décrit dans cette question Ubuntu.

Il était essentiellement un problème de CE calcul sur le côté serveur, ce qui a empêché que la connexion soit établie correctement.

Il y a une différence dans l'ordre de préférence pour les suites de chiffrement entre Java 6 et Java 7 (voir les deux tableaux).

Parce que TLS_RSA_WITH_AES_128_CBC_SHA est plus élevé que tout CE de la suite de chiffrement dans l'ordre de préférence dans la version 6 de Java (et pris en charge par le client et le serveur), il sera choisi lorsque vous vous connectez avec la version 6 de Java client.

Lorsque vous vous connectez avec un Java 7 client, une CE les suites de chiffrement (par exemple TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA ou TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) sera choisi et le serveur va commencer à procéder à cette (vous auriez besoin de voir la poignée de main du journal de débogage sur le côté serveur pour le confirmer). Le serveur devrait alors être fait avec de la suite de chiffrement processus de sélection, mais ne parviennent pas à aller plus loin parce que subséquente d'un bug lors de l'utilisation de cette suite de chiffrement.

Si vous avez un certain contrôle sur le serveur (et si c'est en effet l'exécution d'un serveur basé sur Java), essayez de mettre à niveau vers la dernière JRE de paquets. Vous pouvez également essayer les corrections suggérées dans Ubuntu en question (surtout si il ne l'utilise pas PKCS#11) ou pour désactiver le ecdhe n'suites de chiffrement dans la configuration du serveur.

InformationsquelleAutor Bruno
4

D'un coup d'œil à la configuration de votre serveur (https://www.ssllabs.com/ssltest/analyze.html?d=login.solon.com) par rapport à votre liste de suites de chiffrement dans Java7, il semble que vous n'avez que deux accepté options pour votre suite de chiffrement:
```
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
```
Maintenant, TLS_DHE_RSA_WITH_AES_128_CBC_SHA est considéré comme faible, mais depuis votre serveur déclare pas de préférence pour l'ordre, il peut être de prendre ceci et puis, à défaut de la poignée de main. Pour Java6, il est tout à fait possible, il arrive juste à choisir un plus fort suite. Les options les plus vous donnez, plus vous avez de chances de lui donner une chance de récupérer une faiblesse de chiffrement, de sorte que lorsque vous spécifiez une unique suite à l'utilisation, il réussit. (Même si en regardant la configuration de votre serveur, je ne suis pas sûr de savoir comment vous procurer SSL_RSA_WITH_RC4_128_MD5 pour réussir, car il n'est apparemment pas pris en charge.) Sur cette ligne de pensée, peut-être vous devriez essayer de limiter vos suites de chiffrement pour seulement:
```
TLS_RSA_WITH_AES_128_CBC_SHA
```
Ou plus précisément:
```
sslsocket.setEnabledCipherSuites(new String[] {"TLS_RSA_WITH_AES_128_CBC_SHA"});
```
- Pourquoi le DHE_RSA de chiffrement faibles? TLS_DHE_RSA_WITH_AES_128_CBC_SHA a perfect forward secrecy, TLS_RSA_WITH_AES_128_CBC_SHA ne le fait pas, et ils sont par ailleurs les mêmes.
- Pour répondre à mon propre commentaire, pour quelque raison que ce soit le SunJSSE crypto fournisseur de Java 6 et Java 7 utilise 768 bits DH touches, et il ne semble pas être un moyen de le changer, ce qui est une honte parce que le seul travail est de désactiver DHE suites.
- Je suis heureux que vous étiez en mesure de répondre à votre commentaire car je n'étais pas au courant de cela. =)
InformationsquelleAutor MattSenter
0

C'est Java 7 de problème de compatibilité avec des fichiers de clés. Convertir votre fichier de magasin de clés en .p12 . Il devrait fonctionner à l'aide que.
- D'où vous est venue cette idée? Il n'y a pas de magasin de clés sur le côté client ici.
InformationsquelleAutor Deblina Das
-4

avez-vous d'inclure le truststore lorsque vous exécutez le client?
```
java -Djavax.net.ssl.trustStore=${resources}/localhost.truststore \
-Djavax.net.ssl.trustStorePassword=TRUSTSTORE_PASSWORD -jar client.jar com.acme.RunClient
```
- Lire la question. Il est évident à partir de la trace qu'il a un truststore. En tout cas, une question est. Il a une réponse.
InformationsquelleAutor Henry

Vous devez vous connecter pour publier un commentaire.