La réception de SSLHandshakeException: handshake_failure malgré mon client en ignorant tous les certs

J'ai un programme Java qui se connecte à un serveur web à l'aide de SSL/TLS, et envoie diverses requêtes HTTP sur la connexion. Le serveur est localhost et est à l'aide d'un auto-signé cert, mais mon code est à l'aide personnalisée TrustManagers, et ignore les certificats non valides. Il a parfaitement fonctionné jusqu'à maintenant.

La seule différence sur le serveur, c'est qu'il utilisé pour exécuter jboss 6 et est maintenant en cours d'exécution jboss 7. Je ne suis pas sûr si c'est un problème de configuration, ou si il ya un problème avec mon code, mais j'obtiens les mêmes erreurs si j'essaie de me connecter à l'aide d'autres programmes Java comme WebScarab ou ZAP.

En tout cas, est-ce que je peux faire pour que mon code pour contourner ce problème? Voici l'erreur complète:

Received fatal alert: handshake_failure
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
        at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)
        at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(Unknown Source)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
        at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
        at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
        at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(Unknown Source)

Voici les messages de débogage avant la panne:

main, WRITE: TLSv1 Handshake, length = 75
main, WRITE: SSLv2 client hello message, length = 101
main, READ: TLSv1 Alert, length = 2
main, RECV TLSv1 ALERT: fatal, handshake_failure

InformationsquelleAutor Rsaesha | 2012-03-22

25

Donc j'ai trouvé le problème. Il y a peut-être un bug de Java, mais le client semble amorcer un TLSv1 poignée de main, puis envoie un SSLv2 client hello message, à quel point le serveur rejette la connexion.

Cela se produit même si vous créez votre SSLContext avec une instance de TLS:
```
SSLContext sslContext = SSLContext.getInstance("TLS");
```
La solution est de mettre un système bien avant les tentatives de connexions sont faites:
```
System.setProperty("https.protocols", "TLSv1");
```
Il y a probablement d'autres solutions, mais celle-ci a fonctionné pour moi.
- Vous pouvez être intéressé par ça: stackoverflow.com/a/4686924/372643
- Ouais, j'ai vu que plus tôt, tandis que la recherche Google. Est-ce un bug de Java? Je ne vois pas comment il pourrait/devrait être le comportement par défaut quand j'ai spécifié le SSLContext que TLS.
- Ce n'est pas un bug, c'est par la conception (le SSLv2 est pour la rétro-comp.). Voir JSSE Ref/SSLContext: "Par exemple, getInstance("SSLv3") peut retourner une instance qui met en œuvre les "SSLv3" et "TLSv1" [...] Vous pouvez contrôler les protocoles sont en fait activé pour une connexion SSL en utilisant la méthode setEnabledProtocols(String[] protocoles)". Dans votre cas, https.protocols prend soin de setEnabledProtocols pour HttpsURLConnection.
- Droit, mais cela n'explique pas pourquoi il essaie d'utiliser la SSLv2 client de messages "hello" quand j'ai demandé à utiliser le protocole TLS. Le serveur pris en charge uniquement TLSv1 (en particulier), et de les messages de débogage, il ressemble à Java a lancé un TLSv1 poignée de main, avant de passer à SSL (j'ai mis à jour le post original avec les messages de débogage).
- Un bug similaire m'a hanté pendant des jours. Rsaesha la solution a fonctionné comme un charme. J'ai essayé de vous connecter à un service web exposée par SimpleHttpServerJaxWsServiceExporter. La connexion à partir de Java 7 a fonctionné sans problèmes. La connexion à partir de la version 6 de Java a provoqué l'exception.
InformationsquelleAutor Rsaesha
4

Les informations que vous fournissez est très peu ainsi que votre trace de la pile.

Je vais faire une supposition ici.

Ce que je soupçonne, c'est que dans le nouveau serveur le protocole est TLSv1 tandis que vos clients essaient de se connecter avec SSLv3 (ou moins), et comme un résultat de la négociation échoue.

Changez-vous les clients à utiliser une plus grande version de TLS
ou

Faites votre serveur supporte SSLv3 ainsi. Je sais comment le faire dans Tomcat, mais pas dans JBoss.

Si cela ne fonctionne pas mise à jour le post avec plus d'informations (et un full stack trace).

Vous devez activer le ssl, les informations de débogage -Djavax.net.debug=ssl
- Le plein de trace de pile montre juste la méthode de connexion de ma classe, et quelles que soient les méthodes appel. C'est la même méthode qui a été de travailler avec les versions précédentes du serveur. De toute façon, ici, c'est le debug: pastebin.com/RJqcQwaP Ce qui semble un peu étrange pour moi, c'est que même si je dis à mon programme pour utiliser TLS, il semble vouloir envoyer SSLv2 client de messages "hello".
- certains code client dans le post
- Pour moi aussi face à problème similaire détails ici - serverfault.com/questions/954489/... Comment peut-on Identifier ce décrypter erreur ?
InformationsquelleAutor Cratylus
4

Était-ce jamais résolu?

J'ai eu exactement le même problème, en fait, j'ai été reçu par une poignée de main d'exception, immédiatement après le clientHello. Donc La suite des événements a été
1. Je voudrais présenter mon certificat pour le serveur
2. Serveur imediately répondre avec une poignée de main à l'échec. (Je n'aurais même pas obtenir un Serveur Bonjour de retour).
Finalement, j'ai trouvé que le serveur a été exigeant une plus forte chiffrement/déchiffrement que ce que je l'approvisionnement dans la première phase de négociation (Ie. Le Client et le Serveur n'a pas pu s'entendre sur une mutuelle algorithme de chiffrement à utiliser pour la communication ssl).

J'ai besoin d'installer l'Illimité Java JCE (Java Cryptography Extension de la Politique). Il y a des règles d'exportation sur l'utilisation de cette, de sorte que si vous expédiez votre code d'outre-mer qui peuvent avoir des conséquences..mais c'est ce qui a résolu mon problème.

Ce lien explique comment installer la mise à jour des politiques
http://suhothayan.blogspot.com/2012/05/how-to-install-java-cryptography.html

C'était aussi un grand lien qui m'a aidé à comprendre exactement ce qui se passait
https://support.f5.com/kb/en-us/solutions/public/15000/200/sol15292.html#id

Cela peut ou peut ne pas être le problème, mais lorsque la poignée de main ne parvient pas immédiatement après que le client Bonjour, il semble que le client et le serveur ne peut pas d'accord sur quelque chose (dans de nombreux cas, de ses les algorithmes de chiffrement qu'ils seront mutuellement besoin de communiquer).

InformationsquelleAutor DMHarris
0

Vous voyez cette erreur probablement parce que le fichier de clés que votre JBoss 6 eu accès n'est pas accessible à votre JBoss 7 exemple.

Ce que je recommande est la suivante.

Votre auto-signé certificat de serveur doit être importé dans un truststore
```
keytool -import -alias gridserver -file server.crt -storepass $YOUR_PASSWORD_HERE -keystore server.keystore
```
Ajouter les propriétés suivantes à votre course.conf
```
-Djavax.net.ssl.keyStoreType=pkcs12
-Djavax.net.ssl.trustStoreType=jks
-Djavax.net.ssl.keyStore=clientcertificate.p12
-Djavax.net.ssl.trustStore=server.keystore
-Djavax.net.debug=ssl # very verbose debug. Turn this off after everything looks good.
-Djavax.net.ssl.keyStorePassword=$YOUR_PASSWORD_HERE
-Djavax.net.ssl.trustStorePassword=$YOUR_PASSWORD_HERE
```
- Le serveur fonctionne très bien par le biais d'un navigateur web comme google Chrome ou Firefox, de sorte que le fichier de clés sur le serveur n'est pas la question. La Certification ne devrait pas être un problème non plus, depuis que je suis tout simplement en ignorant tous les certs.
InformationsquelleAutor uaarkoti
0

La trace de la pile est de vous code client et votre client a Reçu [a] alerte fatale'. En d'autres termes, l'erreur SSL qui s'est passé dans Jboss, pas votre client.

Votre côté client personnalisé TrustManagers ont donc rien à faire avec elle. Mon sauvage conjecture est que votre nouveau Jboss 7 est configuré pour exiger le certificat du client et votre client ne se présente pas.

Pour déboguer votre connexion SSL, utilisez openssl et essayez ce qui suit:

openssl s_client -connect jboss.server.com:443

ou est-ce un SSLV3 serveur

openssl s_client -connect jboss.server.com:443 -ssl3

Cela devrait afficher beaucoup d'informations intéressantes.
- Voici la sortie de la première commande: pastebin.com/NvRqdu3f
- Mon sauvage guess est juste que, sauvage. Votre serveur est bien. user384706 vous suis sur la bonne voie. C'est plus probablement un protocole d'incompatibilité de version. Je vois que votre serveur est TLSv1/SSLv3, et vous semblez être l'envoi de SSLv2.
InformationsquelleAutor Bruno Grieder
0

Je pense que cela est lié à une Java 7 bug. Il est difficile d'être sûr, sans plus de détails.

InformationsquelleAutor Michael Munsey
0

Pour moi la solution a été : System.setProperty("https.protocols", "TLSv1.1,TLSv1.2");

InformationsquelleAutor Mahmoud Saleh

Vous devez vous connecter pour publier un commentaire.