|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
How good is this SSL setting for clients? |
« View previous topic :: View next topic » |
Author |
Message
|
pcelari |
Posted: Fri Aug 09, 2019 12:29 pm Post subject: How good is this SSL setting for clients? |
|
|
Chevalier
Joined: 31 Mar 2006 Posts: 411 Location: New York
|
Greetings.
I recently inherited a SSL setting for clients that use MQClient to connect to our service queues. There're hundreds of such clients. The current setting is like this: I make a copy of the qmgr's kdb files including password stash file, remove the qmgr certificate with the label 'ibmwebspheremqqmgrname', but keep all the Signer Chain of certificates in the kdb; then distribute these files together with the CCTD and related files to all clients.
It is my understanding, when I create a certificate request, a secret key is generated. But when the clients receives the package of kdb files, there is no secret key among the signer chain. The only thing that can be trusted is the client is in possession of the signer chain, and nothing more. If someone gives the same package to another party, in theory that party would be able to connect to our qmgr.
I'm not knowledge enough to judge if this is a secure setting. Of course I can also see, if we start creating a certreq for each client, get it signed and receive it into the kdb, each client will have a secret key. But we would end up being responsible for hundred of clients' certificate maintenance - an impossible task.
So overall, how good is such a SSL setting? Any comment would be appreciated. _________________ pcelari
-----------------------------------------
- a master of always being a newbie |
|
Back to top |
|
 |
Vitor |
Posted: Fri Aug 09, 2019 12:45 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Are they actually trying to authenticate the clients, or just encrypt the traffic? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
pcelari |
Posted: Fri Aug 09, 2019 2:48 pm Post subject: |
|
|
Chevalier
Joined: 31 Mar 2006 Posts: 411 Location: New York
|
I just don't see there can be any authentication. There is of course a one-sided one, as the clients can be sure they are sending to the right destination. On the other hand, anyone with the set of kdb files will be able to send encrypted message to us. But isn't that dangerous? On the other hand, isn't that the way web pages communicate with web servers?
I'd like to know if there is anything really bad with this setting? _________________ pcelari
-----------------------------------------
- a master of always being a newbie |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Aug 09, 2019 9:00 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
It all depends on your signer chain. If your cert is CA signed that means the whole world can communicate with you. You might want to require Client Authentication and add records for SSLPEER and Issuer DN into the channel authentication...
Now that seems not really feasible when you have hundreds of clients, or rather looks like a Herculean task. However if you do not add the serial number you should be good until the signer chain changes even though the client renewed their cert...
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Vitor |
Posted: Mon Aug 12, 2019 5:06 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
pcelari wrote: |
I just don't see there can be any authentication. There is of course a one-sided one, as the clients can be sure they are sending to the right destination. |
That was kinda the point of my question. Depending on their risk appetite / network security / site rules / message content they might just be trying to encrypt the data on the understanding that messages from bad actors are excluded by other means.
I'm not judging the fitness of the solution because I don't know all the facts, but it's plausible that if they have messages with low sensitivity on a network with good external controls, the risk / benefit calculation might have led them to save a little maintenance money with this layout. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
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
|
|
|
|