MO71 version 9.0.3 is released

MQGem Software is pleased to announce that a new version of MO71, our GUI Administrative tool for IBM MQ, is now available.

The main features of the release are as follows:-

MO71 Auto Export Authrecs

You can now export Authority Records along with all your other objects

Export of AUTHREC in MQSC format

This was one of the most commonly requested features. You can now export AUTHREC definitions in MQSC format from the object and list dialogs as well as include AUTHRECs in the automatic Queue Manager export list.

API Exerciser enhancements

We are pleased to say that this version allows you to experiment with the MQCONNX, Message Handle and Message Property API calls. More information will be coming soon in another blog post.

Hostname display

When displaying a Channel Status output, MQ will send you the IP address eg.198.51.100.34. However, this is not hugely memorable. You can now ask MO71 to issue a gethostbyaddr() and display the result in a hostname field. You can go even further and put your own description of this in a dns file, MQMON.DNS, and have MO71 display that instead. Read more about this in Displaying host names in MO71.

User Commands

You can define your own commands which are then available in the Queue Manager context menu. Read more about this in Running User Commands in MO71.

Message Operations are now Message Token based

By basing message operations on Message Tokens the message operations such as browse, copy, mode and delete are much faster and more specific.

Can now invoke the MQEdit Message Editor directly

When you are browsing a message you can select ‘Edit…’ from the context menu and the MQEdit product will be started editing the same message, saving you having to re-navigate to that message in another tool. This is possible through the use of Message Tokens. You can also open the MQEdit product from a queue list and a single queue dialog and it will open with the messages from that queue already loaded into the list. Ensure you have MQEdit V9.0.1 (or higher) in order to do this. If you don’t have a licence for MQEdit, these options will not be available.

MO71 Message List Edit Option

If you have the MQEdit product, you’ll get an Edit option

New Default Max. Column preference option

Some MQ fields can now be quite large, for example topic strings, subscription names and subscription selectors. This can mean that lists of objects can be have columns which are wider than you would like. You can now say how wide the column should be by default, and a new ‘…’ indicator shows if there is more to be seen than the column is currently displaying.

New Max Column and Field lengths for HTTP browser output

As above these large MQ fields can mean that the browser output is hard to read or it results in an output with a large horizontal scrollbar. You can now tell MO71 how much data to return in these situations.

More CipherSpecs considered weak

IBM recently updated the list of weak CipherSpecs to include those using the Triple DES algorithm, and so MO71 will not show you those CipherSpecs by default. You can ask MO71 to show you the weak ones in the Location dialog for the queue manager in question, but you will also need to enable them in MQ too if you want to use them. Read more about how in Deprecated CipherSpecs

Support for Command Level 902

UPDATE: With a minor update to MO71 after the release of IBM MQ Continuous Delivery Release 9.0.2, support for Command Level 902 has been added. Read more about the new command level in What’s in Command Levels 90x.


The new version can be downloaded from the MO71 Download Page. Any current licensed users of MO71 can run the new version on their existing licence. If you don’t have a licence and would like to try out MO71 then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.

Advertisements

Deprecated CipherSpecs

Cracked PadlockEarlier in Blog Post: Know your protocol I wrote about how IBM MQ V8 FixPack 2 had deprecated all the SSL 3.0 CipherSpecs and turned them off by default.

Now in FixPack 3 a further set of CipherSpecs have been deprecated so that, by default, attempts to use them will result in a error. The additional CipherSpecs deprecated in FixPack 3 are those which use no encryption; the RC algorithms (RC2 and RC4); and single DES.

UPDATE: Now with APAR IV90867, which is targeted for IBM MQ V8 FixPack 6, a further set of CipherSpecs have been deprecated. The additional CipherSpecs deprecated in FixPack 6 are those which use the Triple DES algorithm.

Whether you are currently on IBM MQ V8 at any of these FixPacs or not, you should consider this as a strong hint to look at your use of any of these CipherSpecs and change to a stronger one where possible.

CipherSpecs now deprecated in IBM MQ V8, highlighted column shows the reason for deprecation.
CipherSpec Name Protocol Used Data Integrity Encryption Deprecated in
Algorithm Bits
AES_SHA_US SSL 3.0 SHA-1 AES 128 V8 FixPack 2
DES_SHA_EXPORT SSL 3.0 SHA-1 DES 56 V8 FixPack 2
DES_SHA_EXPORT1024 SSL 3.0 SHA-1 DES 56 V8 FixPack 2
FIPS_WITH_DES_CBC_SHA SSL 3.0 SHA-1 DES 56 V8 FixPack 2
FIPS_WITH_3DES_EDE_CBC_SHA SSL 3.0 SHA-1 3DES 168 V8 FixPack 2
NULL_MD5 SSL 3.0 MD5 None 0 V8 FixPack 2
NULL_SHA SSL 3.0 SHA-1 None 0 V8 FixPack 2
RC2_MD5_EXPORT SSL 3.0 MD5 RC2 40 V8 FixPack 2
RC4_MD5_EXPORT SSL 3.0 MD5 RC4 40 V8 FixPack 2
RC4_MD5_US SSL 3.0 MD5 RC4 128 V8 FixPack 2
RC4_SHA_US SSL 3.0 SHA-1 RC4 128 V8 FixPack 2
RC4_56_SHA_EXPORT1024 SSL 3.0 SHA-1 RC4 56 V8 FixPack 2
TRIPLE_DES_SHA_US SSL 3.0 SHA-1 3DES 168 V8 FixPack 2
TLS_RSA_EXPORT_WITH_RC2_40_MD5 TLS 1.0 MD5 RC2 40 V8 FixPack 3
TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS 1.0 MD5 RC4 40 V8 FixPack 3
TLS_RSA_WITH_DES_CBC_SHA TLS 1.0 SHA-1 DES 56 V8 FixPack 3
TLS_RSA_WITH_NULL_MD5 TLS 1.0 MD5 None 0 V8 FixPack 3
TLS_RSA_WITH_NULL_SHA TLS 1.0 SHA-1 None 0 V8 FixPack 3
TLS_RSA_WITH_RC4_128_MD5 TLS 1.0 MD5 RC4 128 V8 FixPack 3
ECDHE_ECDSA_NULL_SHA256 TLS 1.2 SHA-1 None 0 V8 FixPack 3
ECDHE_ECDSA_RC4_128_SHA256 TLS 1.2 SHA-1 RC4 128 V8 FixPack 3
ECDHE_RSA_NULL_SHA256 TLS 1.2 SHA-1 None 0 V8 FixPack 3
ECDHE_RSA_RC4_128_SHA256 TLS 1.2 SHA-1 RC4 128 V8 FixPack 3
TLS_RSA_WITH_NULL_NULL TLS 1.2 None None 0 V8 FixPack 3
TLS_RSA_WITH_NULL_SHA256 TLS 1.2 SHA-256 None 0 V8 FixPack 3
TLS_RSA_WITH_RC4_128_SHA256 TLS 1.2 SHA-1 RC4 128 V8 FixPack 3
TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS 1.0 SHA-1 3DES 168 V8 FixPack 6
ECDHE_ECDSA_3DES_EDE_CBC_SHA256 TLS 1.2 SHA-1 3DES 168 V8 FixPack 6
ECDHE_RSA_3DES_EDE_CBC_SHA256 TLS 1.2 SHA-1 3DES 168 V8 FixPack 6

As an alternate way of thinking about it, you should be choosing a CipherSpec from the 14 listed in the following table.

CipherSpecs still supported in IBM MQ V8. All of these are FIPS 140-2 certified.
Platform CipherSpec Name Protocol Used Data Integrity Encryption Suite B Added in
Algorithm Bits
All TLS_RSA_WITH_AES_128_CBC_SHA TLS 1.0 SHA-1 AES 128 No V7
All TLS_RSA_WITH_AES_256_CBC_SHA TLS 1.0 SHA-1 AES 256 No V7
All TLS_RSA_WITH_AES_128_CBC_SHA256 TLS 1.2 SHA-256 AES 128 No V7
All TLS_RSA_WITH_AES_256_CBC_SHA256 TLS 1.2 SHA-256 AES 256 No V7
LUW TLS_RSA_WITH_AES_128_GCM_SHA256 TLS 1.2 AEAD AES-128 GCM AES 128 No V7.1
LUW TLS_RSA_WITH_AES_256_GCM_SHA384 TLS 1.2 AEAD AES-128 GCM AES 256 No V7.1
Not IBM i ECDHE_ECDSA_AES_128_CBC_SHA256 TLS 1.2 SHA-256 AES 128 No V7.1
Not IBM i ECDHE_ECDSA_AES_256_CBC_SHA384 TLS 1.2 SHA-384 AES 256 No V7.1
LUW ECDHE_ECDSA_AES_128_GCM_SHA256 TLS 1.2 AEAD AES-128 GCM AES 128 128 bit V7.1
LUW ECDHE_ECDSA_AES_256_GCM_SHA384 TLS 1.2 AEAD AES-128 GCM AES 256 192 bit V7.1
Not IBM i ECDHE_RSA_AES_128_CBC_SHA256 TLS 1.2 SHA-256 AES 128 No V7.1
Not IBM i ECDHE_RSA_AES_256_CBC_SHA384 TLS 1.2 SHA-384 AES 256 No V7.1
LUW ECDHE_RSA_AES_128_GCM_SHA256 TLS 1.2 AEAD AES-128 GCM AES 128 No V7.1
LUW ECDHE_RSA_AES_256_GCM_SHA384 TLS 1.2 AEAD AES-128 GCM AES 256 No V7.1

I have requested that the table in Knowledge Center: Specifying CipherSpecs is updated to only show the supported CipherSpecs and that the details of the deprecated ones are moved out of the way to a separate page.

EDIT: Knowledge Center has now been updated to only show the supported ones and there is a separate page for the list of Deprecated CipherSpecs.

Re-enabling the deprecated CipherSpecs

Be aware that if you have re-enabled SSL V3.0 CipherSpecs at IBM MQ V8 FixPack 2, and you upgrade to FixPack 3, you will have further re-enabling to do. It is not sufficient simply to re-enable the SSL V3.0 protocol as you did with FixPack 2, you also have to specify the weak CipherSpec you wish to allow use of.

If the CipherSpec you wish to re-enable is an SSL V3.0 CipherSpec one step you will need to do is re-enable the protocol. As detailed in Know your protocol this is done by editing the qm.ini file:-

SSL:

AllowSSLV3=Y

or setting the AMQ_SSL_V3_ENABLE=1 environment variable.

Additionally, to re-enable the specific CipherSpec, you can edit the qm.ini file to provide the name of the CipherSpec you wish to allow to be used:-

SSL:

AllowWeakCipherSpec=TRIPLE_DES_SHA_US

or set the AMQ_SSL_WEAK_CIPHER_ENABLE=TRIPLE_DES_SHA_US environment variable.

This setting can be a list of CipherSpecs, or ‘All’ to turn them all back on.

Without these settings use of a weak CipherSpec at define-time will result in:-

AMQ8242: SSLCIPH definition wrong.

and at run-time will result in an error message thus:-

-------------------------------------------------------------------------------
20/07/2015 17:42:26 - Process(6040.1) User(MUSR_MQADMIN3) Program(runmqchl.exe)
                      Host(GEM45) Installation(800FP3)
                      VRMF(8.0.0.3) QMgr(QM1)
                     
AMQ9674: The channel 'QM1.TO.QM2.SSL01' specified a weak or broken CipherSpec.

EXPLANATION:
The SSL or TLS channel 'QM1.TO.QM2.SSL01' is configured to use a weak or broken
CipherSpec 'TRIPLE_DES_SHA_US'. 

This error occurs when the channel has requested to use a CipherSpec that
utilizes cryptographic algorithms or protocols that are now considered to be
broken or weak. 

The channel did not start.
ACTION:
Ensure that the channel is configured to use a CipherSpec that uses a stronger
set of cryptographic algorithms or a stronger protocol. 

Alternatively, configure the queue manager to re-enable the weaker CipherSpec
'TRIPLE_DES_SHA_US' using the AMQ_SSL_WEAK_CIPHER_ENABLE environment variable,
or via the 'AllowWeakCipherSpec' attribute under the SSL stanza in the qm.ini
file. 
-------------------------------------------------------------------------------

Hopefully you won’t ever need to re-enable these old, weak CipherSpecs, but there’s always the chance that you have a channel that talks to an old version queue manager, and you’ll need one of these weaker CipherSpecs for that purpose. At least with this new re-enablement method you’ll only be allowing the one you need to be used, instead of opening them all up.

IBM resources on the same subject:-

Other resources on the same subject:-


IBM Certified Specialist

Morag Hughson is a Certified IBM MQ Specialist
IBM Certified System Administrator – MQ V8.0
Find her on: LinkedIn: http://uk.linkedin.com/in/moraghughson   Twitter: https://twitter.com/MoragHughson   SlideShare: http://www.slideshare.net/moraghughson

Know your protocol

There are times when it is important to know more about your SSL/TLS secured channel than just that it is running. More recently it has become important to know not just the CipherSpec that it is using but the Protocol as well. By protocol I mean, is it using the old SSL V3.0 protocol, or have you set it up to use the more modern TLS 1.0 or TLS 1.2 protocol?

When can this be important to know? Well, unless you’ve been sleeping in a hut in the outback recently you’ve probably been aware of the POODLE vulnerability and the push to get people off the SSL V3.0 protocol and onto something more modern. Also, in IBM MQ V8 the use of per channel certificate labels requires the use of a TLS CipherSpec (because it relies upon a feature in the TLS protocol that isn’t in the SSL protocol).

So how do you know what the protocol is. Well there are two ways:-

  • If you are pre-801, then you can look up the cipherSpec your channel is using in the table in Knowledge Center, and look for the column entitled “Protocol Used”.
    A few rows pulled from the table in Knowledge Center to demonstrate the columns
    Platform Support CipherSpec Name Protocol Used Data Integrity Encryption Algorithm Encryption Bits FIPS Suite B
    All TRIPLE_DES_SHA_US SSL 3.0 SHA-1 3DES 168 No No
    All TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS 1.0 SHA-1 3DES 168 Yes No
    All TLS_RSA_WITH_AES_128_CBC_SHA256 TLS 1.2 SHA-256 AES 128 Yes No
  • If you have an 801 Queue Manager (see What is an 801 Queue Manager?) then when your channel is running, there is a new attribute displayed when you use the DISPLAY CHSTATUS command which will show you exactly which protocol is in use.

Security Protocol as part of Channel Status

Here are some examples. I have set up certificates and defined three channels, each with a different CipherSpec. I have deliberately chosen one from each protocol as you can see if you compare these definitions to the table above.

1 : DISPLAY CHANNEL(QM1.TO.QM2.SSL*) SSLCIPH

AMQ8414: Display Channel details.

CHANNEL(QM1.TO.QM2.SSL01) CHLTYPE(SDR)

SSLCIPH(TRIPLE_DES_SHA_US)

AMQ8414: Display Channel details.

CHANNEL(QM1.TO.QM2.SSL02) CHLTYPE(SDR)

SSLCIPH(TLS_RSA_WITH_3DES_EDE_CBC_SHA)

AMQ8414: Display Channel details.

CHANNEL(QM1.TO.QM2.SSL03) CHLTYPE(SDR)

SSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA256)

When I run these channels on a queue manager that has V8.0.0 FixPac 2 installed (and has re-enabled the SSL V3.0 protocol – see later), then the output I can view shows me the Security Protocol being used by each channel as you can see in the example output below.

1 : DISPLAY CHSTATUS(QM1.TO.QM2.SSL*) SECPROT

AMQ8417: Display Channel Status details.

CHANNEL(QM1.TO.QM2.SSL01) CHLTYPE(SDR)

CONNAME(127.0.0.1(1702)) CURRENT RQMNAME(QM2)

SECPROT(SSLV3) STATUS(RUNNING) SUBSTATE(MQGET) XMITQ(QM2.SSL01)

AMQ8417: Display Channel Status details.

CHANNEL(QM1.TO.QM2.SSL02) CHLTYPE(SDR)

CONNAME(127.0.0.1(1702)) CURRENT RQMNAME(QM2)

SECPROT(TLSV1) STATUS(RUNNING) SUBSTATE(MQGET) XMITQ(QM2.SSL02)

AMQ8417: Display Channel Status details.

CHANNEL(QM1.TO.QM2.SSL03) CHLTYPE(SDR)

CONNAME(127.0.0.1(1702)) CURRENT RQMNAME(QM2)

SECPROT(TLSV12) STATUS(RUNNING) SUBSTATE(MQGET) XMITQ(QM2.SSL03)

This information is also available via the PCF interface, so tools like MQ Explorer and our MO71 GUI Administrator can also show you the Security Protocol Used (get MO71 V8.0.3 for this functionality).

Security Protocol MO71

MQGem’s MO71 GUI Administrator showing the Security Protocol in use

Note: At the time of the writing, the MQ Explorer does not have the Security Protocol displayable. This has been reported, and I hope to be able to bring you a screenshot of that at a future time.

SSL Protocol disabled by default

I mentioned earlier that I had to re-enable the SSL protocol in order to run this demonstration. That’s the other thing that has changed in V8.0.0 FixPack 2. The SSL protocol is now disabled by default. Trying to define a channel using one of the SSL V3.0 protocol CipherSpecs will result in an error as follows:-

1 : DEFINE CHANNEL(QM1.TO.QM2.SSL01) CHLTYPE(SDR) TRPTYPE(TCP) SSLCIPH(TRIP

LE_DES_SHA_US) CONNAME(‘localhost(1701)’) XMITQ(QM2.SSL01)

AMQ8242: SSLCIPH definition wrong.

If you still have a requirement (hopefully a short term one) to use an SSL V3.0 CipherSpec it is possible to re-enable the SSL V3.0 protocol by editing the qm.ini file:-

SSL:

AllowSSLV3=Y

or by setting the AMQ_SSL_V3_ENABLE=1 environment variable.

The message is very clear however, make sure that you know what protocol you are using. Regularly review your channel CipherSpecs to see whether they still meet your business needs, and STOP using SSL V3.0 CipherSpecs.

Twitter Get this message out!

IBM resources on the same subject:-


IBM Certified Specialist

Morag Hughson is a Certified IBM MQ Specialist
IBM Certified System Administrator – MQ V8.0
Find her on: LinkedIn: http://uk.linkedin.com/in/moraghughson   Twitter: https://twitter.com/MoragHughson   SlideShare: http://www.slideshare.net/moraghughson