| Author |
Message
|
| vicks_mq |
 Posted: Tue Jul 30, 2019 9:38 am Post subject: Whether the connection from client is via SSL or not? |
 |
|
Disciple
Joined: 03 Oct 2017
Posts: 162
|
Hi, How do I know if the connection from client to my SVRCONN channel is in realtime using SSL or not?
Our SVRCONN channel definitions has these 2 parameters defined for SSL
SSLCIPH - TLS_RSA_WITH_AES_128_CBC_SHA256
SSLAUTH - OPTIONAL
and when I checked the status of this channel while it was in Running state, following SSL parameters values are being displayed.
i. SSL KEY RESETS = 0
ii. SSL key reset date = blank
iii. SSL key reset time= blank
iv. SSL cert issuer name = blank.
So, I am not sure whether the client connection is over SSL or not? |
|
| Back to top |
|
 |
| exerk |
| Posted: Tue Jul 30, 2019 10:40 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
The Knowledge Centre clearly states that if SSLCAUTH (not SSLAUTH as you have put above) is set to OPTIONAL that if a client presents a certificate then that certificate will be checked, but if a client does not present a certificate then no check is carried out.
What that means is:
1. A valid certificate can be presented and connection established;
2. An invalid certificate can be presented and connection will fail;
3. No certificate can be presented and connection established.
1. and 3. above presupposes that any authority/CONNAUTH/CHLAUTH checks etc. are passed.
If the running channel, when you check its status, does not show any SSL-related attributes populated (e.g. SSLCIPH) then the channel is obviously not using it.
SSLCAUTH should only be used for fault-finding on a temporary basis IMHO.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 30, 2019 10:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Also be aware there's a difference between a channel checking the certificate presented by the client, and using the unchecked certificate to negotiate SSL handshakes.
I agree with my worthy associate; if the running channel doesn't show SSLCIPH then the client either doesn't support the one you specify in it's certificate, or didn't supply a certificate at all, and the channel is running unencrypted.
Caveat: this is at the MQ level. The link might still be encrypted over the wire by the network. So just because it looks like gibberish in Wireshark doesn't mean MQ is encrypting anything. But it might still be encrypted.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vicks_mq |
| Posted: Tue Jul 30, 2019 11:19 am Post subject: |
|
|
Disciple
Joined: 03 Oct 2017
Posts: 162
|
| exerk wrote: |
The Knowledge Centre clearly states that if SSLCAUTH (not SSLAUTH as you have put above) is set to OPTIONAL that if a client presents a certificate then that certificate will be checked, but if a client does not present a certificate then no check is carried out.
What that means is:
1. A valid certificate can be presented and connection established;
2. An invalid certificate can be presented and connection will fail;
3. No certificate can be presented and connection established.
1. and 3. above presupposes that any authority/CONNAUTH/CHLAUTH checks etc. are passed.
If the running channel, when you check its status, does not show any SSL-related attributes populated (e.g. SSLCIPH) then the channel is obviously not using it.
SSLCAUTH should only be used for fault-finding on a temporary basis IMHO. |
Thank you clarifying this, I did compare this channel with another application SVRCONN channel whereas this particular channel SSL attributes are blank in CHSTATUS command, the other channel I checked has value in SSLCERTI & SSLPEER. |
|
| Back to top |
|
|
| vicks_mq |
| Posted: Tue Jul 30, 2019 11:21 am Post subject: |
|
|
Disciple
Joined: 03 Oct 2017
Posts: 162
|
| exerk wrote: |
3. No certificate can be presented and connection established.
SSLCAUTH should only be used for fault-finding on a temporary basis IMHO. |
I think that made me aware of a loophole which of I was ignorant earlier, if client doesn't present any SSL certificate then even setting up SSL at MQ level and adding those SSL certificates in QMGR are not of any use (Unless I set SSLCAUTH to REQUIRED). |
|
| Back to top |
|
|
| tczielke |
| Posted: Tue Jul 30, 2019 12:51 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
If you define a CipherSuite on the SSLCIPH attribute of the SVRCONN channel (e.g. TLS_RSA_WITH_AES_128_CBC_SHA256), that will enforce that the channel has to use SSL/TLS. SSLCAUTH is more about if the client end is required to present a certificate or not to the queue manager.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
|
|
