SSL/TLS support in MQIPT

Secure sockets protocols

In MQIPT, secure sockets are provided by using the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. The two secure sockets protocols are similar but do not interoperate. In this documentation the terms SSL and TLS are used interchangeably unless a specific difference is noted.

MQIPT supports SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2 provided by the supplied Java runtime environment (JRE). The IBM® MQ CipherSpec of the remote channel determines which protocol MQIPT uses.

SSL 3.0 is insecure and so is disabled by default in MQIPT. TLS 1.0 and TLS 1.1 are also disabled by default in MQIPT from IBM MQ 9.1.4. If you need to use any of these disabled protocols, they can be re-enabled by following the procedure in Enabling deprecated protocols and CipherSuites in MQIPT.

The SSL/TLS protocols can use different digital signature algorithms for authentication of communication parties. The cryptographic operations that are used in SSL/TLS, encryption for data confidentiality, and secure hashing for message integrity, rely on the sharing of secret keys between the client and the server. SSL/TLS provides various key exchange mechanisms that allow for the sharing of secret keys. SSL/TLS can make use of various algorithms for encryption and hashing.

JRE cryptographic component

The SSL/TLS cryptographic component of the JRE contains the IBMJSSEFIPS and IBMJCEFIPS security providers, which are certified compliant with FIPS 140-2 at level 1. These security providers have the highest priority in the JRE so that FIPS-certified implementations are used wherever available. Various cryptographic algorithms are supported; specify them by using SSL/TLS CipherSuites. Not all CipherSuites are FIPS 140-2 certified.

SSL/TLS Bridging Mode

When a route has both the SSLServer and SSLClient set, the MQIPT accepts one incoming SSL/TLS secured connection and establishes a second SSL/TLS secured connection to another MQIPT or to a destination queue manager. The IBM MQ channel information is decrypted and re-encrypted between these two SSL/TLS connections. SSL/TLS bridging is also referred to as an SSL/TLS termination proxy.

IBM MQ supports SSL/TLS bridging using the MQIPT. Other SSL/TLS termination proxies with IBM MQ have been observed to cause broken connections if the proxy combines or reconstructs SSL/TLS records with different sizes than those sent by IBM MQ. This is due to an interaction between the way queue managers allocate and manage memory for incoming IBM MQ network data and the way IBM MQ network data is packaged into SSL/TLS records.

AMQ9638: SSL communications error for channel
AMQ9208: Error on receive from host

SSL/TLS Proxy Mode

An MQIPT route can be configured in SSL/TLS proxy mode as an alternative to SSL/TLS bridging. In this mode, the route only forwards SSL/TLS data between two IBM MQ end-points; it does not participate in the SSL/TLS handshake and does not require any digital certificates.

You can use SSL/TLS proxy mode in cases where the IBM MQ channels which communicate through MQIPT are already configured for SSL/TLS communication and you want to use MQIPT for another purpose, such as routing connections through firewalls or restricting the set of allowable connections through a security exit. When running in SSL/TLS proxy mode, MQIPT checks that the initial SSL/TLS packets received from a new connection are valid before forwarding the packets to the destination.

IBM MQ supports SSL/TLS proxy mode with the MQIPT or any other SSL/TLS proxy

IBM MQ multiple certificate support with MQIPT

IBM MQ 8.0, and later, supports the use of multiple certificates on the same queue manager, using a per-channel certificate label, specified using the CERTLABL attribute on the channel definition. Inbound channels to the queue manager (for example, server connection or receiver) rely on detecting the channel name using TLS Server Name Indication (SNI), in order to present the correct certificate from the queue manager.

If a channel connects to the destination queue manager through MQIPT, and the MQIPT route has both SSLServer and SSLClient set, there are two separate TLS sessions between the endpoints, and the SNI data does not flow across the session break. This prevents a per-channel certificate from being used on the destination queue manager, for the TLS connection between MQIPT and the queue manager. To use a per-channel certificate on the destination queue manager, for a TLS connection that passes through MQIPT, the MQIPT route must use SSL/TLS Proxy Mode, which forwards all TLS control flows intact, including the SNI name.

The certificates that are used for TLS connections that are terminated or initiated by MQIPT can be configured individually for each route, for example by using the SSLServerSiteLabel and SSLClientSiteLabel route properties.

CipherSuites supported by MQIPT

The following table shows which CipherSuites are supported by MQIPT and which are enabled by default.

By default, only a subset of CipherSuites are enabled. CipherSuites based on several algorithms that are considered insecure are disabled by the JRE. If you are aware of the potential hazards but still need to use one of these CipherSuites, you can add support for a disabled CipherSuite by following the procedure in Enabling deprecated protocols and CipherSuites in MQIPT.

CipherSuite	Enabled by default
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_WITH_AES_128_CBC_SHA
SSL_DH_anon_WITH_AES_128_CBC_SHA256
SSL_DH_anon_WITH_AES_128_GCM_SHA256
SSL_DH_anon_WITH_AES_256_CBC_SHA
SSL_DH_anon_WITH_AES_256_CBC_SHA256
SSL_DH_anon_WITH_AES_256_GCM_SHA384
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_DH_anon_WITH_RC4_128_MD5
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_AES_128_CBC_SHA	Yes
SSL_DHE_DSS_WITH_AES_128_CBC_SHA256	Yes
SSL_DHE_DSS_WITH_AES_128_GCM_SHA256	Yes
SSL_DHE_DSS_WITH_AES_256_CBC_SHA	Yes
SSL_DHE_DSS_WITH_AES_256_CBC_SHA256	Yes
SSL_DHE_DSS_WITH_AES_256_GCM_SHA384	Yes
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_RC4_128_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_AES_128_CBC_SHA	Yes
SSL_DHE_RSA_WITH_AES_128_CBC_SHA256	Yes
SSL_DHE_RSA_WITH_AES_128_GCM_SHA256	Yes
SSL_DHE_RSA_WITH_AES_256_CBC_SHA	Yes
SSL_DHE_RSA_WITH_AES_256_CBC_SHA256	Yes
SSL_DHE_RSA_WITH_AES_256_GCM_SHA384	Yes
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_ECDH_anon_WITH_3DES_EDE_CBC_SHA
SSL_ECDH_anon_WITH_AES_128_CBC_SHA
SSL_ECDH_anon_WITH_AES_256_CBC_SHA
SSL_ECDH_anon_WITH_NULL_SHA
SSL_ECDH_anon_WITH_RC4_128_SHA
SSL_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA	Yes
SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256	Yes
SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256	Yes
SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA	Yes
SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384	Yes
SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384	Yes
SSL_ECDH_ECDSA_WITH_NULL_SHA
SSL_ECDH_ECDSA_WITH_RC4_128_SHA
SSL_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
SSL_ECDH_RSA_WITH_AES_128_CBC_SHA	Yes
SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256	Yes
SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256	Yes
SSL_ECDH_RSA_WITH_AES_256_CBC_SHA	Yes
SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384	Yes
SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384	Yes
SSL_ECDH_RSA_WITH_NULL_SHA
SSL_ECDH_RSA_WITH_RC4_128_SHA
SSL_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA	Yes
SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256	Yes
SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256	Yes
SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA	Yes
SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384	Yes
SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384	Yes
SSL_ECDHE_ECDSA_WITH_NULL_SHA
SSL_ECDHE_ECDSA_WITH_RC4_128_SHA
SSL_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA	Yes
SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256	Yes
SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256	Yes
SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA	Yes
SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384	Yes
SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384	Yes
SSL_ECDHE_RSA_WITH_NULL_SHA
SSL_ECDHE_RSA_WITH_RC4_128_SHA
SSL_KRB5_EXPORT_WITH_DES_CBC_40_MD5
SSL_KRB5_EXPORT_WITH_DES_CBC_40_SHA
SSL_KRB5_EXPORT_WITH_RC4_40_MD5
SSL_KRB5_EXPORT_WITH_RC4_40_SHA
SSL_KRB5_WITH_3DES_EDE_CBC_MD5
SSL_KRB5_WITH_3DES_EDE_CBC_SHA
SSL_KRB5_WITH_DES_CBC_MD5
SSL_KRB5_WITH_DES_CBC_SHA
SSL_KRB5_WITH_RC4_128_MD5
SSL_KRB5_WITH_RC4_128_SHA
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (Note 1)
SSL_RSA_FIPS_WITH_DES_CBC_SHA (Note 1)
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_AES_128_CBC_SHA	Yes
SSL_RSA_WITH_AES_128_CBC_SHA256	Yes
SSL_RSA_WITH_AES_128_GCM_SHA256	Yes
SSL_RSA_WITH_AES_256_CBC_SHA	Yes
SSL_RSA_WITH_AES_256_CBC_SHA256	Yes
SSL_RSA_WITH_AES_256_GCM_SHA384	Yes
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA
SSL_RSA_WITH_NULL_SHA256
SSL_RSA_WITH_RC4_128_MD5	Yes
SSL_RSA_WITH_RC4_128_SHA

IBM MQ CipherSpecs and MQIPT CipherSuites

The following table shows the relationship between the CipherSpecs supported by IBM MQ and the CipherSuites supported by MQIPT.

The table also shows the protocol version that IBM MQ expects each CipherSpec to use.

An IBM MQ CipherSpec uniquely determines both the encryption algorithm and also the secure socket protocol version to be used. Some IBM MQ CipherSpecs differ only by protocol version, so it is not sufficient to configure the CipherSuite alone. The SSL/TLS handshake negotiates the highest secure sockets protocol version supported by both sides, and then selects a CipherSuite from the set of mutually enabled ciphers.

For example, an SSLClient route with SSLClientCipherSuites=SSL_RSA_WITH_3DES_EDE_CBC_SHA could negotiate either TLS_RSA_WITH_3DES_EDE_CBC_SHA (TLS 1.0) or TRIPLE_DES_SHA_US (SSL 3.0) with the remote queue manager. In fact it is possible to negotiate this CipherSuite over TLS 1.2, but IBM MQ does not support this CipherSuite over TLS 1.2. For this reason, SSLClient routes are particularly likely to cause AMQ9616 or AMQ9631 errors at the queue manager.

To avoid such errors on SSLClient routes, set the SSLClientProtocols route property to the appropriate value for the intended CipherSpec. In some cases it might also be necessary to restrict the server-side protocol set by using the SSLServerProtocols route property. Use the protocol version shown in the table to determine the correct setting for these route properties.

If you want to use a single MQIPT SSLClient route to tunnel multiple IBM MQ channels that use different CipherSpecs, ensure that all channels have CipherSpecs that use the same secure sockets protocol version as each other and that you set SSLClientProtocols to use this single protocol version.