IBM® MQ for HPE NonStop 'How to' Series Part 2

For many years, MQ products have offered the ability to secure connections over MQ channels using TLS, i.e. Transport Level Security. TLS is the new name for what was previously known as the Secure Sockets Layer, or SSL. TLS technology is used in many scenarios today including many websites that offer it in the form of secure HTTPS connections. TLS provides authentication, integrity and privacy and is the preeminent security technology in today’s commercial world. When configured with TLS, MQ channels can securely send messages over an otherwise insecure network.

The TLS capability in MQ for HPE NonStop has recently been extended to include the ability to use the latest TLS 1.3 ciphers along with a new class of cipherspecs known as alias ciphers. Alias ciphers were introduced in the MQ for Windows, Linux and zOS products in MQ v9.1 and with the release of MQ v8.1 fixpack 7, they are also available on HPE NonStop.

Traditional TLS channels

Setting up a standard TLS channel is relatively simple. The MQ administrator need only choose an available MQ cipherspec, configure both ends of the channel to use that cipherspec with the SSLCIPH attribute, and finally, provide suitable certificates for each participating queue manager.

The above recipe is well known and has been used for many years to setup secure production MQ channels. It is important to recognize that this type of deployment requires the same, specific TLS cipherspec to be configured at each end of the channel pair, like so:

At queue manager ALICE, we define a TLS sender channel like so:

define channel (ALICE.TO.BOB) chltype(SDR) …… SSLCIPH(ECDHE_RSA_AES_128_CBC_SHA256)

and its partner at queue manager BOB,

define channel (ALICE.TO.BOB) chltype(RCVR) …… SSLCIPH(ECDHE_RSA_AES_128_CBC_SHA256)

The same SSLCIPH choice (which in the example above is a modern TLS 1.2 cipherspec called ECDHE_RSA_AES_128_CBC_SHA256) must be configured at each end of the channel-pair.

Doing this isn’t particularly onerous for a few channel-pairs but remember that TLS technology evolves and improves over time and the SSLCIPH choice that seemed reasonable today, will likely need to be reconsidered again in the near-future. MQ is regularly extended with new TLS cipher support and an MQ organization that wants to use the strongest security protocols will be planning to regularly review its TLS channels to remain current with these changes.

Future-proofing your TLS channels using ALIAS ciphers

Using alias ciphers, we can define our MQ TLS channels so they don’t need to reconfigured as often. An alias cipher is the name for a class of MQ cipherspecs that share a common characteristic, namely their TLS protocol. Alias ciphers can be used in any channel’s SSLCIPH specification instead of a specific cipherspec name and using them can reduce the need to change the channel definition as MQ TLS features are rolled out.

These are the basic Alias Cipherspecs offered by MQ v8.1:

ANY	Selects any enabled cipherspec
ANY_TLS12	Selects any enabled cipherspec that uses the TLS 1.2 protocol
ANY_TLS13	Selects any enabled cipherspec that uses the TLS 1.3 protocol

But, these are also provided:

ANY_TLS12_OR_HIGHER	Selects any enabled cipherspec that uses the TLS 1.2 protocol or later
ANY_TLS13_OR_HIGHER	Selects any enabled cipherspec that uses the TLS 1.3 protocol or later

The last two Alias ciphers are particularly interesting. Channel-pairs that use them (ANY_TLS12_OR_HIGHER or ANY_TLS13_OR_HIGHER) will automatically adapt to later, stronger, protocols and cipherspecs as new TLS features are added to MQ.

For example, here’s the previous ALICE and BOB channel’s, redrafted to take advantage of Alias ciphers:

At queue manager ALICE:

define channel (ALICE.TO.BOB) chltype(SDR) …… SSLCIPH(ANY_TLS12_OR_HIGHER)

and its partner at queue manager BOB,

define channel (ALICE.TO.BOB) chltype(RCVR) …… SSLCIPH(ANY_TLS12_OR_HIGHER)

Cipherspec ordering

When using Alias ciphers, modern MQ products will choose the strongest protocol and cipherspecs as specified by the channel definition and the queue manager. When choosing cipherspecs, MQ has a preferred orders for its cipherspecs. This order is the same on different MQ platforms (Windows, Linux, zOS and now HPE Nonstop) and roughly proceeds from strongest to weakest.

This default order for cipherspecs is shown in the MQ documentation here.

Note that you can specify your own list of cipherspecs and specify a different preference order using the SSL: stanza and AllowedCipherSpecs attribute in the qm.ini file.