java.net.SocketException : Tuyau cassé avec JMS/JNDI et les séries MQ

Question

J'ai configuré WebSphere MQ v6.0.1.1 à laquelle un client Java peut accéder en utilisant JNDI y JMS via SSL . J'ai essayé le client et le serveur sur des machines différentes, et sur la même machine. Je n'ai pas eu la même exception du côté client mais c'est lié à un problème de connexion. Du côté du serveur, je n'ai rien dans le journal.

Erreur côté client sur une machine différente : Thread pool thread #0, Exception sending alert: java.net.SocketException: Software caused connection abort: socket write error

*** ServerHelloDone
*** Certificate chain
***
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
Thread pool thread #0, WRITE: TLSv1 Handshake, length = 141
SESSION KEYGEN:
PreMaster Secret:
0000: 03 01 DB 7F 1B 78 46 24   D1 B3 7F 8F E4 2B 2D 35  .....xF$.....+-5
0010: 1B EB FF C9 01 C9 EC 12   07 0F F9 88 A9 12 45 77  ..............Ew
0020: 22 AE 79 17 C2 9D 4C 97   04 3E BA 91 1F 14 68 44  ".y...L..>....hD
CONNECTION KEYGEN:
Client Nonce:
0000: 50 76 7B FB 0D 45 F0 8D   EF 54 E0 AB 2C 3A D4 7D  Pv...E...T..,:..
0010: 24 52 FB FB 4F F4 1D E4   CC 2C 4E BA 8B CA 3E 54  $R..O....,N...>T
Server Nonce:
0000: 00 00 00 00 8F 53 C4 4D   2F 2F 41 AA EB 0A 80 2D  .....S.M//A....-
0010: D0 E4 51 2A CC BC EE 94   92 BD CD E0 9B C9 EB 3D  ..Q*...........=
Master Secret:
0000: 9D 93 ED F3 8A 97 39 7F   71 5F 34 52 30 A6 8E 38  ......9.q_4R0..8
0010: BC 17 59 28 78 63 AA 66   63 D0 EE 1C C6 54 CA D1  ..Y(xc.fc....T..
0020: F2 F0 ED 7E D7 81 33 C6   E3 1B 7C 46 C0 FB C8 5C  ......3....F...\
Client MAC write Secret:
0000: 57 56 3D 05 B1 27 BE 56   A8 FD 07 64 0A 96 62 F2  WV=..'.V...d..b.
0010: AE AF B5 98                                        ....
Server MAC write Secret:
0000: F5 C7 B2 D2 79 11 90 6C   C8 FD 86 8B E5 AE 59 71  ....y..l......Yq
0010: B2 A7 AB D3                                        ....
Client write key:
0000: 54 FD FD 8B C2 B4 8B 3F   38 23 25 5A 8A 41 26 9B  T......?8#%Z.A&.
Server write key:
0000: 6D 9C C0 97 ED 21 3F 0E   0A FB E2 2B EE C0 5F 01  m....!?....+.._.
... no IV used for this cipher
Thread pool thread #0, WRITE: TLSv1 Change Cipher Spec, length = 1
*** Finished
verify_data:  { 182, 85, 56, 238, 250, 233, 155, 119, 224, 254, 23, 196 }
***
Thread pool thread #0, WRITE: TLSv1 Handshake, length = 36
Thread pool thread #0, READ: TLSv1 Change Cipher Spec, length = 1
Thread pool thread #0, READ: TLSv1 Handshake, length = 36
*** Finished
verify_data:  { 215, 140, 30, 150, 82, 161, 85, 160, 127, 189, 226, 74 }
***
%% Cached client session: [Session-1, SSL_RSA_WITH_RC4_128_SHA]
Thread pool thread #0, setSoTimeout(120000) called
Thread pool thread #0, WRITE: TLSv1 Application Data, length = 150
Thread pool thread #0, READ: TLSv1 Application Data, length = 56
Thread pool thread #0, WRITE: TLSv1 Application Data, length = 48
Thread pool thread #0, called close()
Thread pool thread #0, called closeInternal(true)
Thread pool thread #0, SEND TLSv1 ALERT:  warning, description = close_notify
Thread pool thread #0, WRITE: TLSv1 Alert, length = 22
Thread pool thread #0, Exception sending alert: java.net.SocketException: Software caused connection abort: socket write error

Erreur côté client de la même machine : Thread pool thread #0, Exception sending alert: java.net.SocketException: Broken pipe

Il semble que le client écrive alors que le serveur a déjà fermé la connexion.

EDIT:

10/10/12  2:26:23 PM - Process(10995.12) User(mqm) Program(amqrmppa)
AMQ9631: The CipherSpec negotiated during the SSL handshake does not match the
required CipherSpec for channel 'SSL.CHANNEL'.

EXPLANATION:
There is a mismatch between the CipherSpecs on the local and remote ends of
channel 'SSL.CHANNEL'. The channel will not run until this mismatch is
resolved. The CipherSpec required in the local channel definition is
'RC4_SHA_US'. The name of the CipherSpec negotiated during the SSL handshake is
'RC4_SHA_US'. A code is displayed if the name of the negotiated CipherSpec
cannot be determined.
ACTION:
Change the channel definitions for 'SSL.CHANNEL' so the two ends have matching
CipherSpecs and restart the channel. If the certificate in use by one end of
the channel is a Global Server Certificate, then the negotiated CipherSpec may
not match that specified on either end of the channel. This is because the SSL
protocol allows a Global Server Certificate to automatically negotiate a higher
level of encryption. In these cases specify a CipherSpec which meets the
requirements of the Global Server Certificate.
----- amqccisa.c : 851 --------------------------------------------------------
10/10/12  2:26:23 PM - Process(10995.12) User(mqm) Program(amqrmppa)
AMQ9999: Channel program ended abnormally.

EXPLANATION:
Channel program 'SSL.CHANNEL' ended abnormally.
ACTION:
Look at previous error messages for channel program 'SSL.CHANNEL' in the error
files to determine the cause of the failure.
----- amqrmrsa.c : 468 --------------------------------------------------------

Edit 2 :

     1 : DIS CHANNEL(SSL.CHANNEL) SSLCIPH
AMQ8414: Display Channel details.
   CHANNEL(SSL.CHANNEL)                    CHLTYPE(SVRCONN)
   SSLCIPH(RC4_SHA_US)

Le Cipher utilisé côté client en utilisant JMSAdmin :

DEFINE QCF(QCF_NAME) SYNCPOINTALLGETS(YES) HOSTNAME(HOST) PORT(1414) TRANSPORT(client) QMANAGER(MYQMGR) CHANNEL(SSL.CHANNEL) SSLCIPHERSUITE(SSL_RSA_WITH_RC4_128_SHA)

Sur la base de CipherSpecs et CipherSuites SSL RC4_SHA_US semble correspondre SSL_RSA_WITH_RC4_128_SHA .

Answer 1

Lorsqu'on exécute le client sur le même hôte que le QMgr, il est possible de se connecter en utilisant le mode bindings (mémoire partagée) plutôt que la pile réseau. Comme les connexions en mode bindings n'utilisent pas la pile réseau, SSL ne ferait aucune différence.

En supposant que le client se connecte sur le réseau dans les deux cas, il n'y a rien concernant l'emplacement du client sur un serveur ou un autre qui pourrait influencer la connexion SSL, si ce n'est que les configurations du client étaient différentes d'une instance à l'autre. Le client passe toujours par la pile réseau et présente une demande de connexion à l'écouteur de QMgr. Le client trouve son keystore de la même manière et tout ce que le QMgr voit, c'est une demande de connexion présentée au listener. Ainsi, si vous obtenez des résultats différents entre les deux instances du client, recherchez des divergences de configuration.

Ma méthode pour déboguer les connexions SSL sur WMQ consiste à suivre la séquence suivante en m'assurant que chaque étape fonctionne avant de passer à la suivante :

1. Faites fonctionner le canal sans SSL. Cela permet de valider que les noms des canaux sont correctement orthographiés, qu'une route réseau existe entre les points d'extrémité, que le listener de QMgr est en cours d'exécution et que le client pointe sur le bon port.
2. Obtenir le canal en cours d'exécution avec la définition de SVRCONN réglée sur SSLCAUTH(OPTIONAL) . Il s'agit d'une connexion SSL anonyme similaire à celle de votre navigateur. Le QMgr présente un certificat au client mais n'en demande pas en retour. Cela permet de valider que le QMgr peut trouver son certificat et que le client peut trouver son magasin de confiance et valider correctement le certificat du QMgr.
3. Réglez le canal SVRCONN sur SSLCAUTH(REQUIRED) . Le client doit maintenant trouver son keystore (à l'étape précédente, il n'avait besoin que de son trust store) et être capable de trouver son certificat. Il faut également que le QMgr soit en mesure de valider le certificat du client.

La différence entre les deux dernières étapes permet d'isoler le problème en testant l'échange d'informations d'identification SSL dans une seule direction à la fois.

Vous mentionnez qu'il n'y a "rien dans le journal" lorsque cela se produit. Quel journal ? Il existe deux ensembles de journaux d'erreurs. Le premier est le journal global du serveur à l'adresse {WMQ home}/errors et l'autre est le journal d'erreurs de QMgr à {WMQ home}/QMgrs/{QMgr name}/errors . Les entrées du journal des erreurs sont effectuées dans le journal des erreurs du QMgr lorsque le MQ peut identifier le QMgr associé à l'erreur. Cependant, lorsqu'une connexion SSL est demandée, MQ ne sait pas quel QMgr est sollicité par la connexion jusqu'à ce que après la connexion SSL est terminée. Pour cette raison, de nombreuses erreurs de négociation SSL du côté du serveur sont signalées dans le journal des erreurs global.

Je vous suggère de suivre les étapes décrites ci-dessus pour déterminer quel échange d'informations d'identification SSL échoue, puis de rechercher les entrées du journal d'erreurs dans les fichiers journaux d'erreurs QMgr et global. Si cela ne résout pas le problème, veuillez mettre à jour votre question en indiquant l'étape du processus qui échoue et toutes les entrées du journal d'erreurs identifiées par le journal dans lequel elles ont été trouvées.

De plus, la version 6 de MQ a été mise hors service le mois dernier. Le passage à une version prise en charge du client et du serveur WMQ vous permettrait d'ouvrir un PMR, offrirait de bien meilleures performances Java/JMS et vous permettrait d'utiliser des cryptages plus sûrs tels que les hachages SHA-2 et la nouvelle cryptographie à courbe elliptique prise en charge par GSKit 8. WMQ V6 n'étant plus pris en charge, un seul Fix Pack supplémentaire au maximum sera publié, après quoi les vulnérabilités de sécurité de cette version ne seront plus corrigées. Si vous utilisez SSL, je suppose que la sécurité est assez importante et que vous souhaitez utiliser une version qui recevra des correctifs si une nouvelle vulnérabilité est découverte.

UPDATE
Pour répondre à la mise à jour de la question concernant le certificat global du serveur, il est nécessaire de comprendre comment WMQ met en œuvre SSL/TLS. Lorsque la connexion est établie, la négociation TLS (si vous spécifiez un SSL, WMQ exécute une session TLS en utilisant un chiffrement SSL) suit la spécification et la spécification permet une négociation de la suite de chiffrement. Lorsqu'un certificat de serveur global est utilisé, le certificat peut spécifier une puissance de chiffrement minimale acceptable, ce qui influence la négociation.

Lorsque la session TLS se termine avec succès, la connexion est alors transmise à WebSphere MQ. Ce n'est qu'alors que le QMgr vérifie les paramètres du canal, par exemple "pour quel QMgr la connexion est-elle demandée ?" ou, plus important encore, "le cipherspec négocié de la connexion correspond-il à la définition du canal ?" En général, l'échec est dû à une incompatibilité entre le client et le serveur. Avec un certificat de serveur global, il peut échouer à cause d'un désaccord entre le cipherspec négocié et le minimum acceptable. comme spécifié par le certificat .

Le message d'erreur indique qu'il est possible que la suite de chiffrement spécifiée par le client corresponde exactement à la suite de chiffrement spécifiée dans le canal et que la connexion échoue malgré tout, car le certificat du serveur global spécifie une puissance de chiffrement minimale supérieure à celle utilisée par le client et le QMgr. Pour en savoir plus, consultez le site Mauvaise concordance des spécifications de chiffrement dans l'Infocentre mais dans ce cas, le message d'erreur est presque aussi informatif que l'Infocentre.