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* Alias CipherSpecs.

During a TLS handshake, a client and server exchange the CipherSpecs and protocols that they support in order of their preference. A common CipherSpec that both sides prioritize is chosen and used for the TLS communication. When choosing a CipherSpec protocol, version is also considered, for example if a server lists TLS 1.2 CipherSpecs before TLS 1.3 CipherSpecs it will still prioritize TLS 1.3 so long as the client can support it and has a common TLS 1.3 CipherSpec that can be used.

From 8.1.0.7, when IBM® MQ is configured for TLS it sets the CipherSpecs into the order shown in the following table, from most preferred to least preferred.
Note: If a CipherSpec is not enabled through the AllowedCipherSpecs attribute, it will not be configured for use during a TLS Handshake.

In the case that the AllowedCipherSpecs attribute is not specified, a default list of enabled ciphers, indicated by the following table, is used.

Table 1. CipherSpecs order from 8.1.0.7
CipherSpec Protocol Hexadecimal code Enabled by default
TLS_CHACHA20_POLY1305_SHA256 TLS 1.3 1303 Yes
TLS_AES_256_GCM_SHA384 TLS 1.3 1302 Yes
TLS_AES_128_GCM_SHA256 TLS 1.3 1301 Yes
TLS_AES_128_CCM_SHA256 TLS 1.3 1304 Yes
TLS_AES_128_CCM_8_SHA256 TLS 1.3 1305 Yes
TLS_RSA_WITH_AES_256_GCM_SHA384 TLS 1.2 009D Yes
ECDHE_ECDSA_AES_256_GCM_SHA384 TLS 1.2 C02C Yes
ECDHE_RSA_AES_256_GCM_SHA384 TLS 1.2 C030 Yes
TLS_RSA_WITH_AES_256_CBC_SHA256 TLS 1.2 003D Yes
ECDHE_ECDSA_AES_256_CBC_SHA384 TLS 1.2 C024 Yes
ECDHE_RSA_AES_256_CBC_SHA384 TLS 1.2 C028 Yes
TLS_RSA_WITH_AES_128_GCM_SHA256 TLS 1.2 009C Yes
ECDHE_ECDSA_AES_128_GCM_SHA256 TLS 1.2 C02B Yes
ECDHE_RSA_AES_128_GCM_SHA256 TLS 1.2 C02F Yes
TLS_RSA_WITH_AES_128_CBC_SHA256 TLS 1.2 003C Yes
ECDHE_ECDSA_AES_128_CBC_SHA256 TLS 1.2 C023 Yes
ECDHE_RSA_AES_128_CBC_SHA256 TLS 1.2 C027 Yes
ECDHE_ECDSA_3DES_EDE_CBC_SHA256 TLS 1.2 C008 No
ECDHE_RSA_3DES_EDE_CBC_SHA256 TLS 1.2 C012 No
TLS_RSA_WITH_RC4_128_SHA256 TLS 1.2 0005 No
ECDHE_ECDSA_RC4_128_SHA256 TLS 1.2 C007 No
ECDHE_RSA_RC4_128_SHA256 TLS 1.2 C011 No
TLS_RSA_WITH_NULL_SHA256 TLS 1.2 003B No
ECDHE_ECDSA_NULL_SHA256 TLS 1.2 C006 No
ECDHE_RSA_NULL_SHA256 TLS 1.2 C010 No
TLS_RSA_WITH_AES_256_CBC_SHA TLS 1.0 0035 No
TLS_RSA_WITH_AES_128_CBC_SHA TLS 1.0 002F No
TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS 1.0 000A No
TRIPLE_DES_SHA_US SSL v3 000A No
RC4_SHA_US SSL v3 0005 No
RC4_MD5_US SSL v3 0004 No
NULL_SHA SSL v3 0002 No
NULL_MD5 SSL v3 0001 No

Changing the order

If a different order is desired, then a new order of CipherSpecs can be supplied using the AllowedCipherSpecs attribute of the SSL stanza with the following rules:
  • Higher protocol versions are always used, regardless of their position in the list.
  • Any disabled CipherSpecs are re-enabled if supplied in the list.
  • The TLS server's list order has a higher priority than the TLS client.
  • When TLS 1.3 is enabled, certain CipherSpecs are not supported.
For example, if the following is configured on the queue manager: 
SSL:
AllowedCipherSpecs=TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_AES_128_GCM_SHA256,
TLS_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA
then:
  • A client connecting with ANY_TLS12 will likely use the TLS 1.2 CipherSpec TLS_RSA_WITH_AES_128_GCM_SHA256.
  • A client connecting with ANY_TLS12_OR_HIGHER will likely use the TLS 1.3 CipherSpec TLS_AES_128_GCM_SHA256 (assuming the client supports TLS 1.3).
  • A client connecting with the TLS 1.0 CipherSpec TLS_RSA_WITH_AES_256_CBC_SHA will use that CipherSpec.

Providing a custom list of ordered and enabled CipherSpecs

It is possible for you to provide an alternative set of CipherSpecs that are enabled and in your order of preference for use with IBM MQ channels, either using the AMQ_ALLOWED_CIPHERS environment variable or the AllowedCipherSpecs SSL stanza attribute of the .ini file. You may want to use this setting for either of the following reasons:
  • To restrict IBM MQ listeners from accepting incoming channel start requests, unless they use one of the named CipherSpecs.
  • To change the order of priority of CipherSpecs that are used in a TLS handshake.

This functionality can be used to control the CipherSpecs that are included in the ANY* Alias CipherSpecs.

The AMQ_ALLOWED_CIPHERS environment variable or AllowedCipherSpecs SSL stanza attribute accepts:
  • A single CipherSpec name.
  • A comma separated list of CipherSpec names to re-enable.
  • The special value of ALL, representing all CipherSpecs.
Note: You should not enable ALL CipherSpecs, as this will enable SSL 3.0 and TLS 1.0 protocols and a large number of weak cryptographic algorithms.
If this setting is configured, it overrides the default CipherSpec list and causes IBM MQ to ignore weak cipher deprecation settings (see below):
  • IBM MQ listeners only accept SSL/TLS proposals that use one of the named CipherSpecs.
  • IBM MQ channels only allow a blank SSLCIPH value, or one of the named CipherSpecs.
  • runmqsc tab completion of SSLCIPH values restricts the completion values to one of the name CipherSpecs.
For example, if you only want to allow channels to be defined/altered and listeners to accept ECDHE_RSA_AES_128_GCM_SHA256 or ECDHE_ECDSA_AES_256_GCM_SHA384 you could set the following in the qm.ini file: 

SSL:
  AllowedCipherSpecs=ECDHE_RSA_AES_128_GCM_SHA256, ECDHE_ECDSA_AES_256_GCM_SHA384

Additionally, the CipherSpecs in this list will be used to determine the priority of the CipherSpecs used during a TLS handshake. For example, if you specify a list of TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA256 it is likely that, during the handshake, the TLS_RSA_WITH_AES_128_CBC_SHA256 CipherSpec will be chosen over the TLS_RSA_WITH_AES_256_CBC_SHA256 CipherSpec if a client connects specifying both of these CipherSpecs, that is, a client connecting with ANY_TLS12.