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 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 Version 9.1.4. For to use any of these disabled protocols, they can be re-enabled by following the procedure in Enable deprecated protocols and CipherSuites.

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 we 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 we 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. CipherSuites based on several algorithms that are considered insecure are disabled by the JRE. If we are aware of the potential hazards but still need to use one of these CipherSuites, we can add support for a disabled CipherSuite by following the procedure in Enable deprecated protocols and CipherSuites.

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

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.2: MQ CipherSpec TLS_RSA_WITH_RC4_128_SHA256

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.

• SSL/TLS handshake
  The SSL/TLS handshaking process occurs during the initial connection request between the SSL/TLS client and server, when authentication and negotiation of CipherSuites is performed.
• MQIPT implementation of SSL/TLS
  SSL 3.0 and TLS 1.0, 1.1, and 1.2 are implemented with Public Key Cryptography Standards (PKCS) #12 tokens stored in key ring files (with file types of .p12 or .pfx), containing X509.V3 certificates. MQIPT can also use cryptographic hardware key stores that support the PKCS#11 Cryptographic Token Interface standard. MQIPT uses the IBM Java Secure Socket Extension (JSSE) package.
• Encrypting a key ring password
  Encrypt the password used to open a key ring file, or to access cryptographic hardware used by MQIPT, with the mqiptPW command. The encrypted password can be used by any of the following properties: SSLClientKeyRingPW, SSLClientCAKeyRingPW, SSLServerKeyRingPW, SSLServerCAKeyRingPW, and SSLCommandPortKeyRingPW. This topic describes the correct way to store a key ring password for use by MQIPT.
• Selecting certificates from a key ring file
  
• Trust settings
  A key ring contains a personal certificate that includes the signer certificate or chain of signer certificates.
• Testing SSL/TLS
  We can test an SSL/TLS connection by using the examples provided in this documentation.
• SSL/TLS error messages
  
• mqiptKeyman and mqiptKeycmd
  mqiptKeyman (iKeyman) is a certificate and key management application that is already familiar to IBM MQ users. The mqiptKeyman and mqiptKeycmd commands can be used to manage symmetric and asymmetric keys, digital certificates, and certificate requests in key ring files used by IBM MQ Internet Pass-Thru. These files can also be used to manage the key ring files themselves.
• Certificate exit
  
• LDAP and CRLs
  
• Multi-valued certificate Distinguished Name OU properties
  We can match multiple organizational unit (OU) values in certificate Distinguished Names.
• Enable deprecated protocols and CipherSuites
  By default, secure sockets protocols and cipher suites that are considered insecure are disabled in the Java runtime environment (JRE) supplied with MQIPT. These deprecated protocols and cipher suites must be enabled before they can be used.
• Use PKCS #11 cryptographic hardware
  MQIPT can access digital certificates that are stored in cryptographic hardware that supports the PKCS #11 interface.

Parent topic: Configure IBM MQ Internet Pass-Thru