ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Security » Java Client and ANY_TLS12_OR_HIGHER

Post new topic  Reply to topic
 Java Client and ANY_TLS12_OR_HIGHER « View previous topic :: View next topic » 
Author Message
PeterPotkay
PostPosted: Fri Sep 03, 2021 11:45 am    Post subject: Java Client and ANY_TLS12_OR_HIGHER Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

MQ Server is MQ 9.2.0.3
MQ Client is MQ 9.2.0.2. A vendor product that uses the Oracle JRE and the IBM MQ classes for Java API
SVRCONN channel on MQ server is always ANY_TLS12_OR_HIGHER

I would like to get the client side to use ANY_TLS12_OR_HIGHER as well.

-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
Client side Cipher Suite = TLS_RSA_WITH_AES_256_CBC_SHA256
The above works, the channel starts and runs with this CipherSpec

-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
Client side Cipher Suite = ANY_TLS12_OR_HIGHER
Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.

Removed -Dcom.ibm.mq.cfg.useIBMCipherMappings=false
Client side Cipher Suite = ANY_TLS12_OR_HIGHER
Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.

What would you try next?
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Fri Sep 03, 2021 2:36 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

More test results

MQ Server is MQ 9.2.0.3
MQ Client is MQ 9.2.0.2. A vendor product that uses the Oracle JRE and the IBM MQ classes for Java API
SVRCONN Channel on MQ server is always ANY_TLS12_OR_HIGHER

wrapper.java.additional.NN=-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
Client Cipher Suite = TLS_RSA_WITH_AES_256_CBC_SHA256
The above works, the channel starts and runs with this CipherSpec

wrapper.java.additional.NN=-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
Client Cipher Suite = ANY_TLS12_OR_HIGHER
Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.

wrapper.java.additional.NN=-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
Client Cipher Suite = *TLS12ORHIGHER
Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.

wrapper.java.additional.NN=-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
Client Cipher Suite = "*TLS12ORHIGHER"
Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.


Removed wrapper.java.additional.NN=-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
Client Cipher Suite = ANY_TLS12_OR_HIGHER
Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.

Removed wrapper.java.additional.NN=-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
Client Cipher Suite = *TLS12ORHIGHER
Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.

Removed wrapper.java.additional.NN=-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
Client Cipher Suite = "*TLS12ORHIGHER"
Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.


wrapper.java.additional.NN=-Dcom.ibm.mq.cfg.useIBMCipherMappings=true
Client Cipher Suite = ANY_TLS12_OR_HIGHER
Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.

wrapper.java.additional.NN=-Dcom.ibm.mq.cfg.useIBMCipherMappings=true
Client Cipher Suite = *TLS12ORHIGHER
Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.

wrapper.java.additional.NN=-Dcom.ibm.mq.cfg.useIBMCipherMappings=true
Client Cipher Suite = "*TLS12ORHIGHER"
Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
tczielke
PostPosted: Sat Sep 04, 2021 8:47 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

I did a test at 9.2.0.1 on Linux I see similar behavior of a 2400 with a non-IBM JRE using useIBMCipherMappings=false and sslCipherSuite=ANY_TLS12_OR_HIGHER not working. However, switching the sslCipherSuite=*TLS12ORHIGHER did work.

I made this switch by running an MQ Java client trace and seeing that the MQ Java code seemed to be only checking for the following CipherSuite group values:

[*TLS12]
[*TLS13]
[*TLS12ORHIGHER]
[*TLS13ORHIGHER]
[*ANY]

I do see in your test you did try a non-IBM JRE with useIBMCipherMappings=false and sslCipherSuite=*TLS12ORHIGHER and it did not work. My recommendation would be to run the Java client trace and see if the code really passed in *TLS12ORHIGHER for the CipherSuite to MQ and also set com.ibm.mq.cfg.useIBMCipherMappings=false.
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Wed Sep 22, 2021 5:07 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

MQ Client 9.2.0.2 is installed as confirmed by dspmqver.
But then I noticed the running channel has the queue manager showing remote version is 9.1.0.6. What the heck? Reached out to the vendor to explain that one.

I switched to try *TLS12. Using Djavax.net.debug=all I see its failing with MQRC 2400 and MQJE001 before it ever gets to the TLS handshake. I do see *TLS12 in the debug log. Its dying before it even attempts to contact the remote MQ queue manager. If I switch back to a specific TLS 1.2 CipherSuite that works I can see that name in the debug log and then the complete TLS handshake as expected.


So. Then I went to another environment. Same vendor product version. Same MQ Client 9.2.0.2 installed. But this time, the remote queue manager does show the client is using 9.2.0.2. OK. I try all the wild ciphers here.

*TLS12 works!!! channel status shows TLS_RSA_WITH_AES_256_GCM_SHA384 is in use

All the other wild Ciphers fail not with MQRC 2400 but instead with MQRC 2009. What is going on?

Either the MQ Client or the JRE are struggling with these wild card cipher names.

In all test cases for this post:
Remote QM version is 9.2.0.3
SVRCONN channel is set to ANY_TLS12_OR_HIGHER
But if its dying before the TLS handshake even starts, the MQ queue manager side settings are irrelevant.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
tczielke
PostPosted: Thu Sep 23, 2021 5:58 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

For the environment where you see mismatched jar versions, that does sound like there are back-leveled jars somewhere that are getting pulled into this client application. That could also explain the odd behavior with the wildcard CipherSuite names.

Not sure on the 2009 for the other environment. I would expect a 2400 if the CipherSuite that is used is not supported by the IBM MQ client code.
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Mon Sep 27, 2021 2:42 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

I got the the app to use the 9.2.0.2 version of the MQ Client instead of the 9.1.0.6 version it was stuck on. Now *TLS12 works while all other wild card ciphers throw MQRC 2009 instead of MQRC 2400.

Here is what I think is happening. The wild card ciphers were introduced at 9.1.1 and 9.1.4, so the 9.1.0.6 MQ Client did not know what to make of the Ciphers that started with the wild card. And so any and all wild card cipher attempts failed with MQRC 2400. The failure was in the MQ Client layer. Working as designed with a proper MQRC.

Once I switched to 9.2.0.2 MQ Client, all the wild cards should have worked, and they do, from an MQ perspective. What I think is occurring now is the JRE (actually OpenJDK as I dug deeper) is choking on attempts to use any wild card cipher that allows the MQ Server and Client negotiating the TLS handshake to try TLS 1.3 first. The older JRE simply does not even understand what TLS 1.3 is and aborts - the MQ Client then reports the MQRC 2009. But if I force the TLS handshake to only try TLS 1.2 (by using *TLS12) then the older JRE is able to deal with the TLS handshake because its never presented TLS 1.3.

I need to figure out exactly what OpenJDK version supports TLS 1.3 and then see when this vendor product will ship with that version (or newer). In the meantime I will go with *TLS12 on the MQ Client side and keep ANY_TLS12_OR_HIGHER on the MQ Server side.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
tczielke
PostPosted: Tue Sep 28, 2021 4:46 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

In the testing I have done with IBM MQ and TLS 1.3, the Java side had to be at 11 to support TLS 1.3. I believe it was openJDK 11 that was supported, too. It looked like the openJDK 11 also only supported a subset of TLS 1.3, too:

TLS_AES_128_GCM_SHA256 - supported
TLS_AES_256_GCM_SHA384 - supported
TLS_CHACHA20_POLY1305_SHA256 - not supported
TLS_AES_128_CCM_SHA256 - not supported
TLS_AES_128_CCM_8_SHA256 - not supported

Come on, how could you not support a CipherSuite with the name "Cha Cha" in it?
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Tue Sep 28, 2021 8:25 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

The cha cha cipher is the one chosen for my client channel used by MO71 when the MQ client and MQ server are both 9.2.0.3 and the Cipher is set to *TLS12ORHIGHER on both ends.

Since MO71 is C based, there is no blasted JRE involved and so the connection happily chooses a TLS 1.3 connection.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
tczielke
PostPosted: Tue Sep 28, 2021 12:21 pm    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

It sounds like the gskit is doing a good job keeping up then with TLS 1.3.

I was surprised to see you have to go to Java 11 to get some TLS 1.3 support, and only some support at that. Not sure what is going on there. Maybe the Java community is leaning on the Legion of the Bouncy Castle, and you are supposed to plug in Bouncy Castle into your JRE for the full TLS 1.3 CipherSuite support. I haven't validated this, but I do see Bouncy Castle supporting pieces like ChaCha20, AES-CCM, etc. that is needed for the full TLS 1.3 CipherSuites.
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Security » Java Client and ANY_TLS12_OR_HIGHER
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.