MQ

BiteSize Blogging: MQ Version 8 The relationship between MQ CipherSpecs and Java Cipher Suites 

Wed May 19, 2021 12:01 PM

MarkBluemel 2000003172 11,207 Views

Another in the series of bitesize blog posts about features in MQ V8.

I've recently been asked about the relationship of CipherSpecs and Cipher Suites, so I thought I should try to summarise the situation.

What's it all about?

Let's start by considering what we are trying to express with these strings.

This wikipedia page gives a good overview of the basic concept - at each end of a secure network connection, we need to define the authentication, encryption, message authentication code (MAC) and key exchange algorithms used for the connection. For a connection to be successfully negotiated, both ends must agree about all of these parameters of the connection.

Why is it so complicated?

In the context of MQ Classes for Java, or MQ Classes for JMS, the complication arises because of the differences in the naming conventions used for these parameters :-

  1. At the Queue Manager, these are specified by applying an MQ CipherSpec to a channel. The CiperSpecs supported by MQ are documented in the Knowledge Center - this page contains the current list, at the time of writing.
  2. At the client, the support for secure connections is provided by the Java Secure Socket Extension (JSSE) provider configured into the Java Runtime Environment (JRE) in use. The JSSE provider uses Cipher Suites to specify the combination of secure connection parameters.
  3. The JREs normally used with MQ Client applications have different JSSE providers, which support different Cipher Suites, and which use different names for suites describing the same set of parameters.

·       This page shows the Cipher Suites  supported by the IBM JSSE provider, used in IBM JREs, including the "hybrid" JREs supported on some platforms  (A "hybrid" JRE is an Oracle JRE with IBM additions, including the JSSE provider).

·       A table under this heading shows the Cipher Suites supported by the Oracle JSSE provider, used by standard JREs on Solaris and HP/UX platforms. I believe this provider is also used in OpenJDK.

As previously noted, the two ends of the network connection must agree on the parameters used in the connection - so, somehow, we need to ensure that the Cipher Suite configured at the client matches the CipherSpec configured on the Queue Manager channel.

At the Queue Manager channel

There is little choice - you select a set of secure connection parameters and configure the appropriate CipherSpec on your channel.

At the Client

Here you have two choices :-

  1. Determine the Cipher Suite that corresponds to the set of secure connection parameters required - this may, as noted above, depend on which JSSE provider is in use.
    This can then be set, for example, on the ConnectionFactor used in a JMS application.
  2. Specify the CipherSpec used at the channel (again this can be done in the ConnectionFactory for a JMS application) and let the MQ Classes for JMS (or MQ Classes for Java - actually this is done by a common layer underlying both sets of Java classes) deal with the mapping from the CipherSpec to the appropriate Cipher Suite.
    The mapping to be performed is, as shown above, dependent on which JSSE provider is in use - the MQ classes will assume an IBM JSSE provider unless the System Property com.ibm.mq.cfg.useIBMCipherMappings is set to false, in which case the classes will assume an Oracle JSSE provider.

What can we do to make things easier?

I think there is a degree of convergence emerging between the Cipher Suite names used by the different JSSE providers - if this is the case, there is the hope that at some point in the future we will only need one CipherSpec<=>Cipher Suite mapping table and the System Property mentioned above will become redundant.

Unless and until we achieve consistency of naming between the MQ CipherSpecs and a consistent set of Cipher Suites, there will always be a need to map between the MQ description of secure networking parameters and the Java description of the same parameters. I hope this Blog Entry has at least clarified why this is necessary and what the key configuration considerations are.

Reference

The tables below were generated from the Java source used to perform CipherSpec <=> Cipher Suite mappings in MQ Classes for Java and MQ Classes for JMS and show CipherSpecs relate to Cipher Suites for the two JSSE providers.

Table 1. CipherSpecs supported by WebSphere MQ and their equivalent CipherSuites, using the IBM JSSE provider

CipherSpec(s)

Equivalent CipherSuite

Protocol

FIPS-1402 compatible?

ECDHE_ECDSA_3DES_EDE_CBC_SHA256
ECDHE_ECDSA_3DES_EDE_CBC_SHA

SSL_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA

TLSv1.2

true

ECDHE_ECDSA_AES_128_CBC_SHA256

SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLSv1.2

true

ECDHE_ECDSA_AES_128_GCM_SHA256
ECDHE_ECDSA_AES_128_GCM_AEAD

SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLSv1.2

true

ECDHE_ECDSA_AES_256_CBC_SHA384

SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLSv1.2

true

ECDHE_ECDSA_AES_256_GCM_SHA384
ECDHE_ECDSA_AES_256_GCM_AEAD

SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLSv1.2

true

ECDHE_ECDSA_NULL_SHA256
ECDHE_ECDSA_NULL_SHA

SSL_ECDHE_ECDSA_WITH_NULL_SHA

TLSv1.2

false

ECDHE_ECDSA_RC4_128_SHA256
ECDHE_ECDSA_RC4_128_SHA

SSL_ECDHE_ECDSA_WITH_RC4_128_SHA

TLSv1.2

false

ECDHE_RSA_3DES_EDE_CBC_SHA256
ECDHE_RSA_3DES_EDE_CBC_SHA

SSL_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

TLSv1.2

true

ECDHE_RSA_AES_128_CBC_SHA256

SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLSv1.2

true

ECDHE_RSA_AES_128_GCM_SHA256
ECDHE_RSA_AES_128_GCM_AEAD

SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLSv1.2

true

ECDHE_RSA_AES_256_CBC_SHA384

SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLSv1.2

true

ECDHE_RSA_AES_256_GCM_SHA384
ECDHE_RSA_AES_256_GCM_AEAD

SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLSv1.2

true

ECDHE_RSA_NULL_SHA256
ECDHE_RSA_NULL_SHA

SSL_ECDHE_RSA_WITH_NULL_SHA

TLSv1.2

false

ECDHE_RSA_RC4_128_SHA256
ECDHE_RSA_RC4_128_SHA

SSL_ECDHE_RSA_WITH_RC4_128_SHA

TLSv1.2

false

RC4_MD5_EXPORT

SSL_RSA_EXPORT_WITH_RC4_40_MD5

SSLv3

false

FIPS_WITH_3DES_EDE_CBC_SHA

SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA

SSLv3

false

FIPS_WITH_DES_CBC_SHA

SSL_RSA_FIPS_WITH_DES_CBC_SHA

SSLv3

false

TLS_RSA_WITH_3DES_EDE_CBC_SHA

SSL_RSA_WITH_3DES_EDE_CBC_SHA

TLSv1

true

TLS_RSA_WITH_AES_128_CBC_SHA

SSL_RSA_WITH_AES_128_CBC_SHA

TLSv1

true

TLS_RSA_WITH_AES_128_CBC_SHA256

SSL_RSA_WITH_AES_128_CBC_SHA256

TLSv1.2

true

TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_GCM_AEAD

SSL_RSA_WITH_AES_128_GCM_SHA256

TLSv1.2

true

TLS_RSA_WITH_AES_256_CBC_SHA

SSL_RSA_WITH_AES_256_CBC_SHA

TLSv1

true

TLS_RSA_WITH_AES_256_CBC_SHA256

SSL_RSA_WITH_AES_256_CBC_SHA256

TLSv1.2

true

TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_GCM_AEAD

SSL_RSA_WITH_AES_256_GCM_SHA384

TLSv1.2

true

TLS_RSA_WITH_DES_CBC_SHA

SSL_RSA_WITH_DES_CBC_SHA

TLSv1

false

NULL_MD5

SSL_RSA_WITH_NULL_MD5

SSLv3

false

NULL_SHA

SSL_RSA_WITH_NULL_SHA

SSLv3

false

TLS_RSA_WITH_NULL_SHA256

SSL_RSA_WITH_NULL_SHA256

TLSv1.2

false

RC4_MD5_US

SSL_RSA_WITH_RC4_128_MD5

SSLv3

false

TLS_RSA_WITH_RC4_128_SHA256
TLS_RSA_WITH_RC4_128_SHA

SSL_RSA_WITH_RC4_128_SHA

TLSv1.2

false

 

Table 2. CipherSpecs supported by WebSphere MQ and their equivalent CipherSuites, using the Oracle JSSE provider

CipherSpec(s)

Equivalent CipherSuite

Protocol

FIPS-1402 compatible?

ECDHE_ECDSA_3DES_EDE_CBC_SHA256
ECDHE_ECDSA_3DES_EDE_CBC_SHA

TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA

TLSv1.2

false

ECDHE_ECDSA_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLSv1.2

false

ECDHE_ECDSA_AES_128_GCM_SHA256
ECDHE_ECDSA_AES_128_GCM_AEAD

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLSv1.2

false

ECDHE_ECDSA_AES_256_CBC_SHA384

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLSv1.2

false

ECDHE_ECDSA_AES_256_GCM_SHA384
ECDHE_ECDSA_AES_256_GCM_AEAD

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLSv1.2

false

ECDHE_ECDSA_NULL_SHA256
ECDHE_ECDSA_NULL_SHA

TLS_ECDHE_ECDSA_WITH_NULL_SHA

TLSv1.2

false

ECDHE_ECDSA_RC4_128_SHA256
ECDHE_ECDSA_RC4_128_SHA

TLS_ECDHE_ECDSA_WITH_RC4_128_SHA

TLSv1.2

false

ECDHE_RSA_3DES_EDE_CBC_SHA256
ECDHE_RSA_3DES_EDE_CBC_SHA

TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

TLSv1.2

false

ECDHE_RSA_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLSv1.2

false

ECDHE_RSA_AES_128_GCM_SHA256
ECDHE_RSA_AES_128_GCM_AEAD

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLSv1.2

false

ECDHE_RSA_AES_256_CBC_SHA384

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLSv1.2

false

ECDHE_RSA_AES_256_GCM_SHA384
ECDHE_RSA_AES_256_GCM_AEAD

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLSv1.2

false

ECDHE_RSA_NULL_SHA256
ECDHE_RSA_NULL_SHA

TLS_ECDHE_RSA_WITH_NULL_SHA

TLSv1.2

false

ECDHE_RSA_RC4_128_SHA256
ECDHE_RSA_RC4_128_SHA

TLS_ECDHE_RSA_WITH_RC4_128_SHA

TLSv1.2

false

TLS_RSA_WITH_3DES_EDE_CBC_SHA

SSL_RSA_WITH_3DES_EDE_CBC_SHA

TLSv1

true

TLS_RSA_WITH_AES_128_CBC_SHA

TLS_RSA_WITH_AES_128_CBC_SHA

TLSv1

false

TLS_RSA_WITH_AES_128_CBC_SHA256

TLS_RSA_WITH_AES_128_CBC_SHA256

TLSv1.2

false

TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_GCM_AEAD

TLS_RSA_WITH_AES_128_GCM_SHA256

TLSv1.2

false

TLS_RSA_WITH_AES_256_CBC_SHA

TLS_RSA_WITH_AES_256_CBC_SHA

TLSv1

false

TLS_RSA_WITH_AES_256_CBC_SHA256

TLS_RSA_WITH_AES_256_CBC_SHA256

TLSv1.2

false

TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_GCM_AEAD

TLS_RSA_WITH_AES_256_GCM_SHA384

TLSv1.2

false

TLS_RSA_WITH_DES_CBC_SHA

SSL_RSA_WITH_DES_CBC_SHA

TLSv1

false

TLS_RSA_WITH_NULL_SHA256

TLS_RSA_WITH_NULL_SHA256

TLSv1.2

false

TLS_RSA_WITH_RC4_128_SHA256
TLS_RSA_WITH_RC4_128_SHA

SSL_RSA_WITH_RC4_128_SHA

TLSv1.2

false

NULL_MD5

SSL_RSA_WITH_NULL_MD5

SSLv3

false

NULL_SHA

SSL_RSA_WITH_NULL_SHA

SSLv3

false

RC4_MD5_EXPORT

SSL_RSA_EXPORT_WITH_RC4_40_MD5

SSLv3

false

RC4_MD5_US

SSL_RSA_WITH_RC4_128_MD5

SSLv3

false

Modified on by MarkBluemel 2000003172


#IBMMQ


#MQ
#cipher