SSL/TLS support

Secure sockets can be used to ensure communication privacy, communication integrity, and authentication.

Communication privacy

The connection can be made private. The data to be exchanged between the client and the server can be encrypted and only the sender and receiver can make sense of the data. This means that private information, such as credit card numbers, can be transferred securely.

Communication integrity

The connection is reliable. The message transport includes a message integrity check based on a secure hash function.

Authentication

The client can authenticate the server and an authenticated server can authenticate the client. This means that the information is guaranteed to be exchanged only between the intended parties. The authentication mechanism is based on the exchange of digital certificates (X.509v3 certificates).

Secure sockets protocols

In MQIPT, secure sockets are provided by using the Secure Sockets Layer (SSL) and the newer Transport Layer Security (TLS) protocols. The two secure sockets protocols are similar but do not interoperate. Both SSL and TLS provide similar security features and in this documentation the terms are used interchangeably unless a specific difference is noted. MQIPT supports SSL version 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 version 3.0 is insecure and so is disabled by default from version 2.1.0.2 of MQIPT. If you need to use SSL, it can be reenabled by specifying SSLv3 in the SSLServerProtocols and SSLClientProtocols route properties.

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 Proxy Mode

As an alternative to using SSL/TLS secure sockets directly, an MQIPT route can be configured to operate in SSL/TLS Proxy Mode. In this mode, the route only forwards SSL/TLS data between the two IBM MQ end-points; it does not participate in the SSL/TLS handshake and does not require any digital certificates.

We can use SSL/TLS Proxy Mode in cases where the IBM MQ channels that 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 via 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 version 8.0, and later, supports the use of multiple certificates on the same queue manager, using a per-channel certificate label attribute. Inbound channels to the queue manager (for example, server connection or receiver) rely on detecting the channel name using TLS Server Name Indication, in order to present the correct certificate from the queue manager.

If we use MQIPT with a route that has both SSLServer and SSLClient set, there are two separate TLS sessions between the endpoints, and the SNI data will not flow across the session break.

We can use separate MQIPT routes to get multiple certificate support by selecting the appropriate certificate, for example through the SSLServerSiteLabel and SSLClientSiteLabel route properties. Alternatively, use MQIPT SSLProxyMode which forwards all SSL or TLS control flows intact, including the SNI name.

Note that multiple certificates for inbound channels with a certificate label across MQIPT work only if you are using SSL/TLS proxy mode.

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. Use the SSLClientCipherSuites and SSLServerCipherSuites route properties if you want to override the default set of enabled CipherSuites.

• RC4, DHE, and DH ciphers are not supported from MQIPT version 2.1.0.2.
• 3DES ciphers are not supported from MQIPT version 2.1.0.3.
• DES40_CBC, anon, and NULL ciphers are not supported in the latest JRE update for MQIPT version 2.1.0.4.

1. Although this CipherSuite is supported for compatibility with previous versions, it is no longer FIPS-compliant and its use should be avoided.
2. From version 2.1.0.2, if you want these CipherSuites to be enabled as defaults, remove DHE from the jdk.tls.disabledAlgorithms list as described in Note 5.
3. From version 2.1.0.2, if you want these CipherSuites to be enabled as defaults, remove RC4 from the jdk.tls.disabledAlgorithms list as described in Note 5.
4. The second column shows which CipherSuites are enabled as defaults. However, they will only be used if the corresponding algorithm is supported, as indicated in the third column.
5. The third column shows which CipherSuites are supported in version 2.1.0.3 and later. We can add support for CipherSuites that are not normally supported by removing the corresponding algorithm (RC4, DHE, DH, 3DES, or DES) from the list of disabled algorithms (jdk.tls.disabledAlgorithms) in the java.security file, found in mqipt_path/java/jre/lib/security/, where mqipt_path is the location where MQIPT is installed.
6. From version 2.1.0.3, if you want these CipherSuites to be enabled as defaults, remove 3DES and DESede from the jdk.tls.disabledAlgorithms list as described in Note 5.
7. These CipherSuites are not supported after installing the latest JRE update for version 2.1.0.4. We can add support for these CipherSuites by removing the corresponding algorithm (DES40_CBC, anon, or NULL) from the jdk.tls.disabledAlgorithms list as described in Note 5.

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.

• SSL_RSA_WITH_3DES_EDE_CBC_SHA, which corresponds to:
  • SSL 3.0: MQ CipherSpec TRIPLE_DES_SHA_US
  • TLS 1.0: MQ CipherSpec TLS_RSA_WITH_3DES_EDE_CBC_SHA
• SSL_RSA_WITH_DES_CBC_SHA, which corresponds to:
  • SSL 3.0: MQ CipherSpec DES_SHA_EXPORT
  • TLS 1.0: MQ CipherSpec TLS_RSA_WITH_DES_CBC_SHA
• SSL_RSA_WITH_RC4_128_SHA, which corresponds to:
  • SSL 3.0: MQ CipherSpec RC4_SHA_US
  • TLS 1.0: MQ CipherSpec TLS_RSA_WITH_RC4_128_SHA256

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.

1. Although this CipherSuite is supported for compatibility with previous versions, it is no longer FIPS-compliant and its use should be avoided.