PH34231: MQ V9.2 Z/OS: CSQX207E, CSQX504E TYPE=0000000B DATA=00000000, CSQX053E -- OCCUR FOR BACK-LEVEL SSL CLIENT CONNECTIONS

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• After migration of the queue manager to MQ 9.2, some older
  client (SVRCONN) channel connections that use SSL/TLS might
  fail with these messages:
  
  +CSQX053E CSQXFFST Error information recorded in CSQSNAP data
  set
  +CSQX207E CSQXRESP Invalid data received,
   connection <ip address>
   (queue manager ????)
   TRPTYPE=TCP
  +CSQX504E CSQXRESP Local protocol error,
   channel
   type=0000000B data=00000000
  
  The CSQSNAP information includes:
  - a couple of entries for XFFSccxAllocMem (routine ccxAllocMem)
  - an entry from XFFSrriBadDataReceived (routine
    rriBadDataReceived)
    The data associated with this entry includes
    00000004 20009504.
    - 00000004 corresponds with an internal constant of
      xfpPROBE_4, which comes from module CSQXCCCX in this case.
    - 20009504 corresponds with message CSQX504E.
  - an entry with a "Data Received" eyecatcher
  - in the reported case, where PH14225 was not applied, there
    were a couple of extra entries for
    - XFFSxcsFreeOwnedBuffers (routine xcsFreeOwnedBuffers)
    - "First 1K of unfreed buffer"
  
  The client channel sent an SSL V3 Client Hello as part of the
  handshake, and it included a TLS extension. Code changes were
  introduced in MQ V920 to parse TLS extensions with
  client-supplied 'Supported Versions'.
  
  The SSL 3.0 protocol (IETF RFC 6101) states under 'Client
  Hello':
  "Forward compatibility note: In the interests of forward
  compatibility, it is permitted for a client hello message to
  include extra data after the compression methods. This data
  must be included in the handshake hashes, but must otherwise be
  ignored."
  
  Therefore, MQ should ignore the TLS extensions for SSL 3.0
  client hellos, which will allow these connections to be
  accepted.
  

Local fix

• Use a newer CIPHERSPEC for the client connection so that a
  higher protocol will be used.  Reference the list at
  https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.2.0/com.
  ibm.mq.sec.doc/q134760_.htm
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 2 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: If a client application sends invalid   *
  *                      TLS extensions then FFSTs and CSQSNAPs  *
  *                      will occur in the CHINIT. This is       *
  *                      expected, but incorrect checking in the *
  *                      MQ receiver code leads to TLS           *
  *                      extensions from SSL 3.0 and TLS 1.0     *
  *                      client hellos being marked as invalid.  *
  ****************************************************************
  The SSL and TLS specifications permit TLS extensions to be sent
  by pre-TLS 1.2 clients, but that they must be ignored. The MQ
  receiver code tries to parse these extensions, which can lead to
  FFSTs and CSQSNAPs if they contain unexpected data. This
  behaviour is correct for TLS 1.2 and later client hellos, but
  not for pre-TLS 1.2 hellos.
  

Problem conclusion

• The MQ receiver code has been corrected to ignore TLS extensions
  from SSL 3.0 and TLS 1.0 client hellos.
  

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:

  UI74364

Modules/Macros

• CSQXCCCX
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R200 PSY UI74364

     UP21/03/26 P F103

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.