A question that the MQ development team has been increasingly asked in recent months is â€ścan I disable TLS v1.0 connections for a queue manager?â€ť. This is of particular interest to MQ users wishing to comply with industry standards – such as PCI DSS – which are moving away from TLS v1.0, as well as MQ users who are proactively adopting secure transfer protocols across their infrastructure.
For users in this position, new function has been released in MQ fix packs 184.108.40.206, 220.127.116.11, and 9.0.5 on distributed platforms to request that the queue manager always rejects connections which propose the TLS v1.0 protocol.
The IBM MQ Knowledge Center describes how to opt-in to this new function:
New attribute to allow TLS v1.0 to be optionally disabled on a queue manager
I donâ€™t have any channel definitions using TLS v1.0 CipherSpecs, do I need to take any action?
As the name suggests, TLS applies to the transport layer, whereas MQ channels are an application layer concept. This means that the TLS handshake happens before the channel name is flowed to the queue manager by the initiating side of the connection (either an MQ client or outbound channel process)1.
As such, the queue manager will accept any enabled protocol level and CipherSpec during the handshake. Once the handshake is complete, the requested channel name is flowed by the initiating side of the connection. At this point the queue manager checks the definition of the received channel name. If the CipherSpec (and implied protocol version) negotiated during the handshake does not match the CipherSpec defined on the channel definition, then connection will be ended immediately be the queue manager. An AMQ9631 error will be recorded in the queue managerâ€™s error log stating the channel name and incorrect CipherSpec proposed by the initiating side of the connection.
Because this validation takes place during the initial connection (before the MQCONN request is sent to the queue manager), then no messaging data is flowed over the connection if the proposed CipherSpec does not match the CipherSpec configured on the channel.
This means that if all channel definitions are configured to use a TLS v1.2 cipherSpec, then TLS v1.2 will always be used to protect messaging data.
For some users, this position will likely be sufficient.
For other users, in particular those who run port scanning tools which only consider the transport layer, this may require further discussion, since TLS v1.0 connections will be accepted at the transport, even though they will never be used for messaging data. In this case, users may find it desirable to disable TLS v1.0 entirely using one of the new options. Once disabled, any connection attempts to the queue manager which propose TLS v1.0 will be rejected at the transport layer.
 From MQ v8 onwards, some clients and outbound channels use server name indication (SNI) to hint at the desired channel name during the TLS handshake. This is to facilitate per-channel certificates, and does not affect the concepts under discussion in this article.