When data is sent between a queue manager and a remote queue, the queue manager opens a channel to the remote queue manager that owns the queue. By default, if the remote queue is protected, for example with a cryptor, the channel is given exactly the same level of protection as the queue. For efficiency in queue-based security, an MQe channel uses symmetric cryptors (for example, DES, 3DES, MARS, RC4, RC6); a consequence of which is that the two queue managers at either end must use the same encryption key. When such a channel is established, a protocol, called the Diffie Hellman key exchange, is used to establish a secret key that only the two queue managers know.
This protocol is susceptible to a "man in the middle" attack, but for that to be successful, the "man in the middle" must know some of the data that is fed into the Diffie Hellman protocol. This data is held in the com.ibm.mqe.attributes.MQeDHk class. It is possible for an attacker to get hold of this data, by examining the shipped MQe classes. However, this data can be changed by running the com.ibm.mqe.attributes.MQeGenDH utility; it generates a new Java™ source file com.ibm.mqe.attributes.MQeDHk.java. This file can then be compiled into a replacement com.ibm.mqe.attributes.MQeDHk.class file.
When the com.ibm.mqe.attributes.MQeWTLSCertAuthenticator is used, the two queue managers (or queues) swap certificates in order to authenticate each other. If this is used in conjunction with a cryptor on the queue, the exchanges which establish the secret key for the cryptor are protected with the public keys from the certificates, making a "man in the middle" attack even more difficult.
With synchronous remote queues, queue-based security is relatively simple. In this case a message is put to a synchronous remote queue definition that has the same security attributes as the destination queue. The message is transmitted over a channel with appropriate security attributes and is stored on the secure queue.
With asynchronous remote queues, especially Store-and-forward queues and Home-server queues, the transmitting and receiving queues are more likely to have different security attributes. These differences have to be managed during message transfer. Once a message has been put to an asynchronous queue it is transmitted from one queue to another until it reaches its destination. A queue manager is responsible for requesting the transfer of the message between a pair of queues and another queue manager is responsible for responding to the request. If queue based security is used, the requesting queue manager establishes a channel with security attributes that match the queue that it owns. The queue manager receiving the request checks that the channel attributes are sufficient for its queue.
For example, suppose a client queue manager has a queue with a DES cryptor on it and messages are routed from this to a server's Store-and-forward queue that has a MARS cryptor. When the client is triggered to send a message it establishes a DES encrypted channel to the server; the server asks the Store-and-forward queue whether it will accept messages over a DES encrypted channel. If the Store-and-forward queue considers DES is not as strong as its own MARS cryptor (determined by the queue attribute rule), it would throw an "attribute mismatch" exception.
A Home-server queue trying to pull messages from a Store-and-forward queue needs a cryptor that is at least as strong as that on the Store-and-forward queue, because the Home-server queue is at the initiating end of the request. Once the Home-server queue has received the message it can store it on a local queue that has any level of protection. This behavior can be changed by using different attribute rules on the queues. For example, if the attribute rule always allows reuse, the queue will accept channels with any cryptor.
Trying to send a message from a queue with a weaker cryptor to a queue with a stronger cryptor usually results in an "attribute mismatch" exception. However if a channel with a strong cryptor already exists between the queue managers, this can be reused (depending on the attribute rules on the channel) and result in the message being delivered.
One slight exception to the above behavior is when a Store-and-forward queue is used to forward (push) messages to other queues. The Store-and-forward queue establishes a channel with security attributes that match its own. However, in this case the destination queue accepts the channel without checking its attributes against the queue's. For example, a Store-and-forward queue without a cryptor would establish a channel without a cryptor and this would be used to forward messages to a destination queue even if the queue had a cryptor on it. Normally, with other queue types, this would result in an "attribute mismatch" exception. When using a Store-and-forward queue in this way, you should ensure that it has a cryptor that is comparable to any cryptor on a destination queue. This does not apply when a Home-server queue polls for messages from a Store-and-forward queue (in this case the Home-server queue establishes the channel, not the Store-and-forward queue).