IT45299: IBM MQ classes for Java and classes for JMS applications using aTLS 1.3 cipher fail if key resets are enabled.

APAR status

• Closed as program error.

Error description

• An IBM MQ classes for JMS application is configured to use the
  following Connection Factory to connect to a queue manager:
  
  QMANAGER: QM1
  TRANSPORT: Client
  HOSTNAME: localhost
  PORT: 1414
  CHANNEL: SECURE.SVRCONN
  SSLCIPHERSUITE: TLS_AES_256_GCM_SHA384
  SSLRESETCOUNT: 32768
  
  When the application starts up, it successfully connects to the
  queue manager, opens a queue and starts consuming messages.
  However, after approximately 32,500 bytes have been send to, and
  received from, the queue manager, the application unexpectedly
  blocks for approximately 5 minutes before receiving a
  JMSException containing reason code 2538
  (MQRC_HOST_NOT_AVAILABLE). An example of the exception is shown
  below:
  
  com.ibm.msg.client.jms.DetailedIllegalStateException:
  JMSWMQ2002: Failed to get a message from destination '<queue
  name>'.
  IBM MQ classes for JMS attempted to perform an MQGET; however
  IBM MQ reported an error.
  Use the linked exception to determine the cause of this error.
  ExceptionListener called for exception:
  com.ibm.msg.client.jms.DetailedIllegalStateException:
  JMSWMQ1107: A problem with this connection has occurred.
  An error has occurred with the IBM MQ JMS connection.
  Use the linked exception to determine the cause of this error.
   at
  com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(
  Reason.java:489)
  
    at
  com.ibm.msg.client.wmq.common.internal.Reason.createException(Re
  ason.java:215)
    at
  com.ibm.msg.client.wmq.internal.WMQMessageConsumer.checkJmqiCall
  Success(WMQMessageConsumer.java:222)
    at
  com.ibm.msg.client.wmq.internal.WMQMessageConsumer.checkJmqiCall
  Success(WMQMessageConsumer.java:156)
    at
  com.ibm.msg.client.wmq.internal.WMQConsumerShadow.getMsg(WMQCons
  umerShadow.java:1859)
    at
  com.ibm.msg.client.wmq.internal.WMQSyncConsumerShadow.receiveInt
  ernal(WMQSyncConsumerShadow.java:233)
    at
  com.ibm.msg.client.wmq.internal.WMQConsumerShadow.receive(WMQCon
  sumerShadow.java:1462)
    at
  com.ibm.msg.client.wmq.internal.WMQMessageConsumer.receive(WMQMe
  ssageConsumer.java:674)
    at
  com.ibm.msg.client.jms.internal.JmsMessageConsumerImpl.receiveIn
  boundMessage(JmsMessageConsumerImpl.java:1051)
    at
  com.ibm.msg.client.jms.internal.JmsMessageConsumerImpl.receive(J
  msMessageConsumerImpl.java:465)
  ......
  Caused by: com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call
  failed with compcode '2' ('MQCC_FAILED') reason '2538'
  ('MQRC_HOST_NOT_AVAILABLE').
    at
  com.ibm.msg.client.wmq.common.internal.Reason.createException(Re
  ason.java:203)
    ... 10 more
  

Local fix

Problem summary

• ****************************************************************
  USERS AFFECTED:
  This issue affects three categories of user:
  
  Category 1:
  --------------
  Users of the IBM MQ classes for Java who have applications that
  use an MQEnvironment with:
  
  - The sslCipherSuite field set to either the name of a TLS1.3
  cipher, or the alias ciphers ANY_TLS13 or ANY_TLS13_OR_HIGHER
  - And the sslResetCount field set to a value greater than 0.
  
  Category 2:
  --------------
  Users of the IBM MQ classes for JMS who have applications that
  are configured to use a Connection Factory that has:
  
  - The SSLCIPHERSUITE property set to either the name of a TLS1.3
  cipher, or the alias ciphers ANY_TLS13 or ANY_TLS13_OR_HIGHER
  - And the SSLKEYRESET property set to a value greater than 0.
  
  Category 3:
  --------------
  Users of the IBM MQ Resource Adapter who have activation
  specifications or connection factories that are configured with:
  
  - The sslCipherSuite field set to either the name of a TLS1.3
  cipher, or the alias ciphers ANY_TLS13 or ANY_TLS13_OR_HIGHER
  - And the sslResetCount field set to a value greater than 0.
  
  
  Platforms affected:
  MultiPlatform
  
  ****************************************************************
  PROBLEM DESCRIPTION:
  The IBM MQ classes for Java, classes for JMS and resource
  adapter use an internal component called the Java Message
  Queueing Interface (JMQI) to communicate with a queue manager.
  The JMQI is responsible for sending data to, and receiving
  responses from, a queue manager.
  
  If an MQ classes for Java or classes for JMS application, or an
  application or activation specification running inside of an
  application server, creates a secure connection to a queue
  manager using a TLS CipherSuite, the JMQI will:
  
  - Establish a TCP/IP connection to the queue manager system.
  - Call the method
  SSLSocket.addHandshakeCompletedListener(HandshakeCompletedListen
  er() to register an internal HandshakeCompletedListener object
  which will be notified whenever a handshake has finished on the
  connection
  - And then call the Java method SSLSocket.startHandshake() to
  start the handshake.
  
  The queue manager and the Java Secure Socket Extensions (JSSE)
  layer provided by the Java Virtual Machine (JVM) then perform
  the handshake. Once it has completed, and the JVM has called the
  HandshakeCompletedListener, the JMQI can start transmitting data
  over the connection.
  
  Now, if key resets were enabled, the JMQI would keep a count of
  the number of bytes that had been sent and received over the
  connection. Once the specified number of bytes had been
  processed, the JMQI would do the following:
  
  - Call SSLSocket.invalidate() to invalidate the current session.
  - Call SSLSocket.startHandshake() to perform a new handshake
  over the connection.
  - Wait for the HandshakeCompletedListener to be called.
  
  For TLS 1.2 ciphers (and earlier), this worked well. After the
  key reset (and a new handshake) had completed, the JVM would
  call the HandshakeCompletedListener and the JMQI would start
  sending and receiving data over the connection again.
  
  However, when using a TLS 1.3 cipher, the JSSE layer and the
  queue manager would send KeyUpdate flows (as specified in the
  TLS 1.3 RFC) rather than performing a full handshake (these
  flows would piggyback on the next application data flows). As a
  result, the JVM did not call the HandshakeCompletedListener and
  so the JMQI would block waiting for data. Some time later, the
  queue manager would send a heartbeat request down the connection
  to check that the application using it was still there. Because
  the JMQI was not expecting this, it generated an internal
  exception which resulted in either an MQException or a
  JMSException containing reason code 2358
  (MQRC_HOST_NOT_AVAILABLE) to be thrown to the application,
  depending on the API that was being used.
  

Problem conclusion

• To resolve this issue, the JMQI has been updated to check which
  TLS protocol is being used when doing a key reset:
  
  - If the protocol is TLS 1.2 or earlier, then the JMQI will wait
  for the HandshakeCompletedLisener to be called before finishing
  the key reset.
  - If the protocol is TLS 1.3, the JMQI will finish the key reset
  operation as soon as the call to SSLSocket.startHandshake() has
  finished.
  
  This allows the JMQI to successfully perform a key reset,
  regardless of the protocol of the cipher being used.
  
  In addition to this, some extra trace has been added to the
  internal methods that perform the key resets, to make it easier
  to diagnose issues in this area in the future.
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
  Version    Maintenance Level
  v9.4 LTS   9.4.0.0
  
  The latest available maintenance can be obtained from
  'IBM MQ Recommended Fixes'
  https://www.ibm.com/support/pages/recommended-fixes-ibm-mq
  
  If the maintenance level is not yet available information on
  its planned availability can be found in 'IBM MQ
  Planned Maintenance Release Dates'
  https://ibm.biz/mqplannedmaintenance
  
  ---------------------------------------------------------------
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  MQ BASE V9.3

• Fixed component ID

  5724H7291

Applicable component levels