Enable CipherSpecs
Enable a CipherSpec by using the SSLCIPH parameter in either the DEFINE CHANNEL or ALTER CHANNEL MQSC command.
Some of the CipherSpecs that we can use with IBM MQ are FIPS compliant. Some of the FIPS compliant CipherSpecs are also Suite B compliant although others, such as TLS_RSA_WITH_AES_256_CBC_SHA, are not.
All Suite B compliant CipherSpecs are also FIPS compliant. All Suite B compliant CipherSpecs fall into two groups: 128 bit (for example, ECDHE_ECDSA_AES_128_GCM_SHA256) and 192 bit (for example, ECDHE_ECDSA_AES_256_GCM_SHA384),
The following diagram illustrates the relationship between these subsets:
From Version 9.2.0, IBM MQ supports the TLS 1.3 security protocol on all platforms. On IBM MQ for z/OS, TLS 1.3 is supported only on z/OS Version 2.4 or later.
The CipherSpecs that we can use for each of these platforms are listed in Table 1. For information about using these CipherSpecs, see Use TLS 1.3 in IBM MQ and IBM MQ MQI client and TLS 1.3. We can configure the default CipherSpecs as described in Default CipherSpec values enabled in IBM MQ. We can also provide an alternative set of CipherSpecs that are enabled for use with channels on:- IBM MQ for Multiplatforms, as described in Providing a custom list of ordered and enabled CipherSpecs on IBM MQ for Multiplatforms.
- IBM MQ for z/OS, as described in Providing a custom list of ordered and enabled CipherSpecs on IBM MQ for z/OS.
Deprecated CipherSpecs that we can re-enable to use with IBM MQ if necessary are listed in Deprecated CipherSpecs. For information about enabling the deprecated CipherSpecs, see Enable deprecated CipherSpecs on IBM MQ for Multiplatforms or Enable deprecated CipherSpecs on z/OS.
CipherSpecs that we can use with IBM MQ TLS support
CipherSpecs that we can use with the IBM MQ queue manager automatically are listed in the following table. When you request a personal certificate, you specify a key size for the public and private key pair. The key size that is used during the TLS handshake is the size stored in the certificate unless it is determined by the CipherSpec, as noted in the table.
Platform support 1 | CipherSpec name | Protocol used | Data integrity | Encryption algorithm | Encryption bits | FIPS 2 | Suite B |
---|---|---|---|---|---|---|---|
Alias CipherSpecs | |||||||
All |
ANY_TLS13_OR_HIGHER 3 4 5 | Negotiated | Negotiated | Negotiated | Negotiated | Negotiated | Negotiated |
All |
ANY_TLS13 4 5 6 | TLS 1.3 | Negotiated | Negotiated | Negotiated | Negotiated | Negotiated |
All |
ANY_TLS12_OR_HIGHER 4 5 7 | Negotiated | Negotiated | Negotiated | Negotiated | Negotiated | Negotiated |
All |
ANY_TLS12 8 | TLS 1.2 | Negotiated | Negotiated | Negotiated | Negotiated | Negotiated |
All |
ANY 9 | Negotiated | Negotiated | Negotiated | Negotiated | Negotiated | Negotiated |
CipherSpecs for TLS 1.3 | |||||||
All |
TLS_AES_128_GCM_SHA2564 5 | TLS 1.3 | GCM | AES-128 with GCM | 128 | No | No |
All |
TLS_AES_256_GCM_SHA3844 5 | TLS 1.3 | GCM | AES-256 with GCM | 256 | No | No |
All |
TLS_CHACHA20_POLY1305_SHA2564 5 | TLS 1.3 | POLY1305 | CHACHA20 | 256 | No | No |
|
TLS_AES_128_CCM_SHA256 | TLS 1.3 | CBC-MAC | AES-128 with CTR | 128 | No | No |
|
TLS_AES_128_CCM_8_SHA256 11 | TLS 1.3 | CBC-MAC | AES-128 with CTR | 128 | No | No |
CipherSpecs for TLS 1.2 | |||||||
All | TLS_RSA_WITH_AES_128_CBC_SHA25610 | TLS 1.2 | SHA-256 | AES | 128 | Yes | No |
All | TLS_RSA_WITH_AES_256_CBC_SHA256 10 12 | TLS 1.2 | SHA-256 | AES | 256 | Yes | No |
All | TLS_RSA_WITH_AES_128_GCM_SHA256 10 13 | TLS 1.2 | SHA-256 and AEAD GCM | AES | 128 | Yes | No |
All | TLS_RSA_WITH_AES_256_GCM_SHA38410 12 13 | TLS 1.2 | SHA-384 and AEAD GCM | AES | 256 | Yes | No |
All | ECDHE_ECDSA_AES_128_CBC_SHA256 10 | TLS 1.2 | SHA-256 | AES | 128 | Yes | No |
All | ECDHE_ECDSA_AES_256_CBC_SHA384 10 12 | TLS 1.2 | SHA-384 | AES | 256 | Yes | No |
All | ECDHE_RSA_AES_128_CBC_SHA256 10 | TLS 1.2 | SHA-256 | AES | 128 | Yes | No |
All | ECDHE_RSA_AES_256_CBC_SHA384 10 12 | TLS 1.2 | SHA-384 | AES | 256 | Yes | No |
|
ECDHE_ECDSA_AES_128_GCM_SHA256 12 13 | TLS 1.2 | SHA-256 and AEAD GCM | AES | SHA384 | Yes | 128 bit |
|
ECDHE_ECDSA_AES_256_GCM_SHA384 12 13 | TLS 1.2 | SHA-384 and AEAD GCM | AES | SHA384 | Yes | 192 bit |
All | ECDHE_RSA_AES_128_GCM_SHA256 13 | TLS 1.2 | SHA-256 and AEAD GCM | AES | 128 | Yes | No |
All | ECDHE_RSA_AES_256_GCM_SHA384 12 13 | TLS 1.2 | AEAD AES-128 GCM | AES | SHA384 | Yes | No |
Notes:
|
Use TLS 1.3 in IBM MQ
From Version 9.2.0, IBM MQ supports TLS 1.3 on all platforms. Before Version 9.2.0, TLS 1.3 support was available on UNIX, Linux, and Windows for Continuous Delivery from Version 9.1.4.
Queue managers that are created at Version 9.2.0 or later support TLS 1.3 by default. Queue managers migrated from earlier versions of IBM MQ need to have TLS 1.3 enabled. We can enable TLS 1.3 on migrated queue managers by setting the AllowTLSV13=TRUE property:- For IBM MQ for Multiplatforms queue managers,
edit the qm.ini file and add the
AllowTLSV13=TRUE property under the SSL stanza (link to
SSL: AllowTLSV13=TRUE
- For IBM MQ for z/OS queue managers, edit
The QMINI data set specified in
the queue manager startup JCL and add the AllowTLSV13=TRUE
property under the TransportSecurity
stanza
TransportSecurity: AllowTLSV13=TRUE
When TLS 1.3 is enabled, and in accordance with the TLS 1.3 specification, any attempt to communicate with a weak CipherSpec, regardless of whether they are enabled in IBM MQ or not, is rejected. The CipherSpecs that TLS 1.3 considers weak are CipherSpecs that meet one or more of the following criteria:
- Uses the SSL 3.0 protocol.
- Uses RC4 or RC2 as the Encryption algorithm.
- Has a encryption key size (bit) equal to or less than 112.
These restrictions are flagged with Note [10] in Table 1 of Deprecated CipherSpecs. For to continue using such CipherSpecs, then we must disable TLS 1.3 mode:
- Edit the queue manager's qm.ini file and change the setting
of the AllowTLSV13 property
to:
SSL: AllowTLSV13=FALSE
- Edit The QMINI data set of the queue manager and change the setting of the
AllowTLSV13 property
to:
TransportSecurity: AllowTLSV13=FALSE
IBM MQ MQI client and TLS 1.3
When using the IBM MQ MQI client, the value of AllowTLSV13 is inferred unless it is explicitly specified in the SSL stanza of the mqclient.ini file that is being used by the application.- If any weak CipherSpecs are enabled, AllowTLSV13 is set to FALSE and no TLS 1.3 CipherSpecs can be used.
- Otherwise, AllowTLSV13 is set to TRUE and the new TLS 1.3 CipherSpecs and alias CipherSpecs can be used.
Default CipherSpec values enabled in IBM MQ
In default configuration for a new IBM MQ queue manager, IBM MQ provides support for the TLS 1.2 and TLS 1.3 protocols and various cryptographic algorithms using CipherSpecs. For compatibility purposes, IBM MQ can also be configured to use SSL 3.0 and TLS 1.0 protocols and a number of cryptographic algorithms that are known to be weak or susceptible to security vulnerabilities. The list of CipherSpecs that are enabled in default configuration may change by applying maintenance.
It is possible to configure IBM MQ to restrict or permit the use of CipherSpecs using the following controls:- Only permit FIPS 140-2 compliant CipherSpecs using SSLFIPS.
- Only permit NSA Suite B compliant CipherSpecs using SUITEB.
- Permit a custom list of CipherSpecs using AllowedCipherSpecs.
- Permit a custom list of CipherSpecs using the AMQ_ALLOWED_CIPHERS environment variable.
- Permit the use of deprecated CipherSpecs using AllowWeakCipher or the AMQ_SSL_WEAK_CIPHER_ENABLE environment variable.
- Permit the use of deprecated CipherSpecs using DD statements in the CHINIT JCL.
Note: If you specify a custom list of CipherSpecs using AllowedCipherSpecs or AMQ_ALLOWED_CIPHERS this overrides enablement of any deprecated CipherSpecs. Note that when using either NSA Suite B or FIPS 140-2 restrictions in combination with a custom CipherSpec list, we must ensure the custom list only contains CipherSpecs permitted by the Suite B or FIPS 140-2 settings.
- CipherSpec order in TLS handshake
The order of CipherSpecs is used when choosing between multiple possible CipherSpecs, for example when using one of the ANY* CipherSpecs. - Deprecated CipherSpecs
A list of deprecated CipherSpecs that we are able to use with IBM MQ if necessary. - Relationship between alias CipherSpec settings
This information describes the expected behavior with different combinations of alias CipherSpecs in client and server configurations. Here, a client refers to the entity initiating communication, for example a client application or a queue manager sender channel, and server refers to the entity receiving the communication from the client, for example a server-connection channel or a receiver channel. - Obtaining information about CipherSpecs using IBM MQ Explorer
We can use IBM MQ Explorer to display descriptions of CipherSpecs. - Alternatives for specifying CipherSpecs
For those platforms where the operating system provides the TLS support, the system might support new CipherSpecs that are not included in Enable CipherSpecs. - Specify a CipherSpec for an IBM MQ MQI client
We have three options for specifying a CipherSpec for an IBM MQ MQI client. - Specify a CipherSuite with IBM MQ classes for Java and IBM MQ classes for JMS
IBM MQ classes for Java and IBM MQ classes for JMS specify CipherSuites differently from other platforms. - Specify a CipherSpec for IBM MQ.NET
For IBM MQ.NET we can specify the CipherSpec either by using the MQEnvironment class or by using the MQC.SSL_CIPHER_SPEC_PROPERTY in the hash table of connection properties.
Parent topic: Confidentiality of messages
Related concepts
- Digital certificates and CipherSpec compatibility in IBM MQ
- CipherSpecs and CipherSuites
- Configure IBM MQ for Suite B
- Federal Information Processing Standards (FIPS)
Related information
- DEFINE CHANNEL
- ALTER CHANNEL
- Change, Copy, and Create Channel
- Migrating existing security configurations to use the ANY_TLS12_OR_HIGHER CipherSpec