Problem Description
As I mentioned in one the previous posts: MQCSP structures, containing the user ID and password of the user being authenticated, are sent in the clear across the network, if you’re not using TLS to encrypt your traffic.
For example, if you setup LDAP for authentication (as described in the previous post), start your MQ Explorer, fill out user ID and password, and connect on a SYSTEM.ADMIN.SVRCONN default channel, the user ID and password, sent to the queue manager by the MQ Explorer, are not protected in any way.
In this post, we will check out ways to remedy that.
How to protect the MQCSP structure
First, and easiest, and most secure is to use TLS on your channels. In this case, MQCSP will be encrypted along with the rest of the traffic going over the channel.
Second option is to protect the MQCSP structure. To be precise, we’re protecting the password in the MQCSP structure. The user ID is not protected. IBM MQ provides this functionality out of the box starting with version 8.0.
You need to meet all of the following conditions for MQCSP password protection to work:
1. Both ends of the connection are using IBM MQ version 8.0 or later.
2. The channel is not using TLS encryption. A channel is not using TLS encryption if the channel has a blank SSLCIPH attribute, or the SSLCIPH attribute is set to a CipherSpec that does not provide encryption. Null ciphers, for example, NULL_SHA, do not provide encryption.
3. You set MQCSP.AuthenticationType to MQCSP_AUTH_USER_ID_AND_PWD in your client code (or configuration screen). The default value of MQCSP.AuthenticationType is MQCSP_AUTH_NONE. With the default setting, no password protection is done.
These three conditions are enough for all applications, but one. For MQ Explorer there is an additional condition that must be met:
4. User identification compatibility mode must not be enabled. This is not the default, you must disable it explicitly.
If these conditions are not met, the password is sent in plain text unless prohibited by the PasswordProtection configuration setting. If the conditions are not met and PasswordProtection configuration setting prohibits plain text password, you will receive an error.
The PasswordProtection configuration setting
You set the PasswordProtection attribute in the Channels stanza of the client and queue manager .ini configuration files. Example:
Channels:
PasswordProtection=always
The attribute can take one of the following values.
compatible
The password can be sent in plain text if either the queue manager or client is running a version of IBM MQ earlier than version 8.0. That is, plain text passwords are allowed for compatibility. This is the default value.
always
The password must be either encrypted with a CipherSpec that is not a null CipherSpec, or MQCSP.AuthenticationType must be set to MQCSP_AUTH_USER_ID_AND_PWD. Otherwise, the connection fails. That is, plain text passwords are not allowed.
optional
The password can optionally be sent protected, but is sent in plain text if MQCSP.AuthenticationType is not set to MQCSP_AUTH_USER_ID_AND_PWD. That is, plain text passwords are allowed to be sent by any client.
warn
Plain text passwords are allowed to be sent by any client. If a plain text password is received a warning message (AMQ9297) is written to the queue manager error logs.
Note about pure Java and JMS clients
Additional considerations for pure Java and JMS clients and PasswordProtection attribute
For Java and JMS clients, the behavior of the PasswordProtection attribute changes dependent on the choice of using compatibility mode or MQCSP mode:
- In compatibility mode, an MQCSP structure is not flowed during connection processing. Therefore, the behavior of the PasswordProtection attribute is the same behavior as described for clients that are running a version of IBM MQ earlier than version 8.0.
- In MQCSP mode, the behavior of the PasswordProtection attribute is the behavior as described.
As you can see from the above description, setting up TLS on all your channels is the simplest, most secure, and the proper way to protect your user IDs and passwords sent across from clients to the queue managers!
Let me know what you think in the comments.
