Mark P Wilson
Published on 04/12/2018 / Updated on 20/12/2018
IBM MQ version 9.1.1 has improved the channel security capability to try and make changing the channel CipherSpec easier. This feature is available on all MQ CD platforms including z/OS.
The issue
Since SSL was added to IBM MQ there has been a fixed link between the protocol and the cipher suite that is used on the channel. To update which cipher is used the MQ administrator has to update both ends of the channel to match.
What is new?
We have added an alias CipherSpec called ANY_TLS12 which means any CipherSpec that MQ supports that uses the TLS 1.2 protocol. This lets MQ decide which CipherSpec to used providing it uses the protocol. Instead of giving one specific cipher to the cryptographic provider a list is given. The cryptographic provider will negotiate the CipherSpec based on what is permitted on both ends. The current list of MQ CipherSpecs that are use the TLS 1.2 protocol are:
- TLS_RSA_WITH_AES_128_CBC_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA256
- ECDHE_ECDSA_AES_128_CBC_SHA256
- ECDHE_ECDSA_AES_256_CBC_SHA384
- ECDHE_RSA_AES_128_CBC_SHA256
- ECDHE_RSA_AES_256_CBC_SHA384
To help to know what CipherSpec and protocol is in effect the DISPLAY CHSTATUS (and the PCF Inquire Channel Status) output now contains the following on all platforms:
- SSLCIPH: This shows the current CipherSpec that is active on the channel.
- SECPROT: This shows the current protocol that is being used. This was added in 8.0.0.2 on distributed platforms. This can be either:
How does this help?
By using the new ANY_TLS12 the MQ administrator is saying ‘I don’t mind which cipher, just as long as it uses the TLS 1.2 protocol’. If in the future one of the ciphers is deprecated the channel will still be able to connect as it will use another cipher. This means that there is no need to change the channel.
What can I see on the channel?
In the examples below I have defined a sender-receiver type channel with ANY_TLS12 as the SSLCIPH, between queue managers MQ25 and MQ26:
CSQM201I !MQ25 CSQMDRTC DIS CHANNEL DETAILS
CHANNEL(SSLCIPH.ANY)
CHLTYPE(SDR)
QSGDISP(QMGR)
XMITQ(SSLCIPH.ANY.XMITQ)
CONNAME(Localhost(1526))
SSLCIPH(ANY_TLS12)
CERTLABL()
END CHANNEL DETAILS
CSQM201I !MQ26 CSQMDRTC DIS CHANNEL DETAILS
CHANNEL(SSLCIPH.ANY)
CHLTYPE(RCVR)
QSGDISP(QMGR)
SSLCIPH(ANY_TLS12)
CERTLABL()
END CHANNEL DETAILS
When the channel is running the following can be seen via the DISPLAY CHSTATUS command:
CSQM201I !MQ25 CSQMDRTC DIS CHSTATUS DETAILS
CHSTATUS(SSLCIPH.ANY)
CHLDISP(PRIVATE)
XMITQ(SSLCIPH.ANY.XMITQ)
CONNAME(127.0.0.1)
CURRENT
CHLTYPE(SDR)
STATUS(RUNNING)
SUBSTATE(MQGET)
STOPREQ(NO)
RQMNAME(MQ26)
SECPROT(TLSV12)
SSLCIPH(TLS_RSA_WITH_AES_256_CBC_SHA256)
END CHSTATUS DETAILS
How do I migrate to use ANY_TLS12?
If a channel pair is using a CipherSpec which is using a protocol that is not TLS 1.2 then both ends of the channel have to be changed to ANY_TLS12 at the same time.
If the channel is using a CipherSpec which is using a protocol that is TLS 1.2 and you want to change to use the ANY_TLS12 capability a second approach can be taken. You can do it in two stages;
- Change the SSLCIPH on the server/receiving end of the channel. As the SSLCIPH on the client/sender is one covered in ANY_TLS12 the channel will succeed to connect but just use that particular CipherSpec.
- The SSLCIPH at the client/sender end of the channel can be altered to used ANY_TLS12. When the channel is restarted the channel will be able to choose from any TLS 1.2 CipherSpec.
Other Considerations
- There are some CipherSpecs that use the TLS 1.2 protocol that use elliptic-curve ciphers. These need a special certificate that have a key type of ‘NIST ECC’, which can only be used for the elliptic-curve ciphers and the other set of ciphers can only use the ‘RSA’ key type of certificates. This limits the choice of ciphers that can be used.
Conclusion
MQ has implemented ANY_TLS12 to make managing SSL/TLS channels easier. The output of display channel status has been changes to be able to see what protocol and CipherSpec is being used.
For more information and migrating to it see Migrating existing security configurations to use the ANY_TLS12 CipherSpec