| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| TLS/SSL offload, cleartext to MQ - password issue |
View previous topic :: View next topic |
| Author |
Message
|
| daboochmeister |
 Posted: Tue Dec 06, 2022 2:11 pm Post subject: TLS/SSL offload, cleartext to MQ - password issue |
 |
|
Newbie
Joined: 06 Dec 2022
Posts: 2
|
Hi - our MQ configurations are not configured to support TLS/SSL, and the work to enable TLS on the MQ side will take some time. In the meantime, we have been given a req't to encrypt the client traffic to the degree possible, and are setting up our F5s to provide a TLS VIP, then talk unencrypted back to the MQ channel.
We actually have 2 F5s involved, one in our DMZ (to which clients connect) and one on our internal network, which is proxied to by the DMZ F5, and which in turn proxies the connections cleartext to MQ. so the flow is:
client - (TLS) -> DMZ F5 - (TLS) -> Internal F5 - cleartext -> MQ
The DMZ F5 does bridging, i.e., it actually performs a TLS handshake with the client, and opens a separate TLS connection to the internal F5. The MQ security is such that the userid and password flow cleartext to MQ (confirmed via captures of existing traffic to MQ, where clients are connecting directly).
We are having an issue where the client (a Mulesoft IBM MQ adaptor) connects cleanly, and we see the messages being proxied to MQ (when we do a capture on the internal F5 of the cleartext packets going to MQ) ... but the client suddenly severs the connection, with an error like:
| Quote: |
IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2594' ('MQRC_PASSWORD_PROTECTION_ERROR')
|
(This all happens within 300 ms, right at the connection attempt - so we're not dealing with timeouts expiring or any such)
We're reasonably confident that the F5s aren't the issue, in that if we turn off TLS on the client and DMZ F5 (but still leave the TLS on for the connection from the DMZ F5 to the internal one), the proxying all works perfectly; and, in captures of the TLS connection from the client to the DMZ F5, the TLS handshake looks fine - and in fact, after the successful handshake, two "INITIAL_DATA" MQ packets are proxied to MQ, and the replies proxied back to the client. It's only after that point that the client seems to sever the connection, and issue the error msg above.
We don't have access at this point to the MQ channel configuration nor error logs (organizational stovepipes). Very frustrating, but trying to solve this in the meantime, whilst that's being negotiated.
In comparing the packets proxied to/from MQ for a successful (no client TLS) and unsuccessful (with client TLS), the only difference we see is that when the client is using TLS, the first INITIAL_DATA packet has the "Gen ConnTag Cap" bit set in CapFlag3 (these are how Wireshark has the fields labeled). In the first reply from MQ for that packet, the "Gen ConnTag Cap" flag is set as well, and the "Prot Algorithms" bit is set in the byte labeled ECapFlag3. Those same bits are set in the 2nd INITIAL_DATA request/reply.
Our suspicion is that the client having TLS enabled causes it to attempt to negotiate password protection, maybe? And that the negotiation fails?
We attempted to suppress use of MQCSP via
| Quote: |
| -Dcom.ibm.mq.cfg.jmqi.useMQCSPauthentication=N |
, but that didn't work; but honestly, we're not sure MQCSP is even being used, not having any visibility into the configuration of the channel at this point; and if it IS being used, we don't want to turn it off, we just want to make the client just send the password cleartext, like it is when no TLS is configured in the client.
In any case, is there any guidance on configuring the client to work properly in such a case, where MQ is naive to the fact that TLS is being used by the client, and is expecting and only supporting a cleartext set of credentials? Or any other hints appreciated!
Obrigado. |
|
| Back to top |
|
 |
| hughson |
| Posted: Tue Dec 06, 2022 10:51 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
Looking at the explanation MQRC_PASSWORD_PROTECTION_ERROR I suspect that the queue manager believes the channel is not using TLS (which matches your description) and so expects the client to have negotiated a password protection mechanism, but since the client thinks it is using TLS then it won't have done this.
Have you tried setting PasswordProtection in the qm.ini file to warn ?
See MQCSP password protection
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| markt |
| Posted: Tue Dec 06, 2022 10:53 pm Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 503
|
|
| Back to top |
|
|
| daboochmeister |
| Posted: Wed Dec 07, 2022 12:23 am Post subject: |
|
|
Newbie
Joined: 06 Dec 2022
Posts: 2
|
Thank you for replying - when you say to look at am.ini, that’s on the queue manager side (on the mainframe, in our case), correct? If so, we simply don’t have access to it, and the mainframe team claims they can’t help us, for whatever reason. Is there any way to detect what settings are in play from the details of the INITIAL_DATA msgs exchanged?
I will say, though - the password is sent plaintext when the client is NOT using TLS (we see it in the msg USER_DATA msg sent by the client, in that scenario). The queue manager can’t “know” at the network level that the client is using TLS (because the connection from the internal F5 to the queue manager is the same either way, and is not using TLS) - so either the client is “notifying” the qm that TLS is in use (that “gen conntag cap” bit being set, maybe?) and the qm is using different settings as a result, or the client is simply not supporting a plaintext password, as a result of its use of TLS (which is counterintuitive). Given that the reply from mq changes to having a bit labeled “prot alg” set in its response, I’m guessing it’s the former - and we’re out of luck until we can negotiate help from the mainframe team. But, we want to rule out that we can somehow control it from the client side (e.g., find some way to prevent that “gen conntag cap” bit from being set?)
Hmm … I may try rewriting the client msg to unset that bit. That’s not straightforward on the F5 (it uses TCL for all such custom scripting, in which I’m not an expert), but may be worth a try.
Any add’l thoughts appreciated. At least it’s an interesting problem, should be thankful for that, I guess!
Peace. |
|
| Back to top |
|
|
|
|
|
|
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
