ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Security » SSL Encryption & Authentication using SVRCONNs

Post new topic  Reply to topic
 SSL Encryption & Authentication using SVRCONNs « View previous topic :: View next topic » 
Author Message
saurabh25281
PostPosted: Thu Jul 25, 2019 12:22 pm    Post subject: SSL Encryption & Authentication using SVRCONNs Reply with quote

Centurion

Joined: 05 Nov 2006
Posts: 107
Location: Bangalore

Hi All,

I am trying to validate my statements regarding SSL encryption & authentication options that are available on server connection channels.

1. When the SSLCIPH are specified but the SSLCAUTH is optional, it basically is a 1-way authentication done one the basis of QMGR certificates & this also performs encryption of messages during transit.

2. When the SSLCIPH are specified and the SSLCAUTH is required, it performs a 2-way authentication of both the client & Qmgr.

So my question is
1. Are the statements/assumptions correct?
2. Does the 2nd point i.e. when SSLCAUTH=required also performs encryption during transit?
3. Is there any configuration that purely does encryption during transit but does not authenticate the client?

Regards
Saurabh
Back to top
View user's profile Send private message Send e-mail Yahoo Messenger
hughson
PostPosted: Thu Jul 25, 2019 7:32 pm    Post subject: Re: SSL Encryption & Authentication using SVRCONNs Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

saurabh25281 wrote:
So my question is
1. Are the statements/assumptions correct?

Almost. When SSLCAUTH(OPTIONAL) is configured, it means the queue manager is willing to accept connections from anonymous (i.e. unauthenticated) clients. However, if a client connects and sends a certificate on such a channel, the certificate is still authenticated. So 2-way authentication will still take place on a channel configured for SSLCAUTH(OPTIONAL) it's just that it doesn't have to.

saurabh25281 wrote:
2. Does the 2nd point i.e. when SSLCAUTH=required also performs encryption during transit?

Whether encryption is performed during transit is not a factor controlled by SSLCAUTH, but by the SSLCIPH you choose. There are some (old and weak) cipherspecs that provided a NULL encryption algorithm. When using those cipherspecs, regardless of the value of SSLCAUTH, and regardless of whether 1-way or 2-way authentication was done, the data wouldn't be encrypted.

saurabh25281 wrote:
3. Is there any configuration that purely does encryption during transit but does not authenticate the client?

No. In order to do encryption, the two ends of the channel must agree a secret key. In order to send that secret key without someone being able to intercept it, they must first obtain a assymmetric key from the certificate, so at least one certificate must be involved (the queue manager's) in order to encrypt the delivery of the secret key that allows bulk data to be encrypted in transit. This is how SSL/TLS connections work.

If you want encryption without digital certificates, you should look for other solutions that don't use SSL/TLS, such as vendor supplied exits.

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
fjb_saper
PostPosted: Fri Jul 26, 2019 4:41 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

3) I beg to differ.
What you are looking for here is an anonymous encryption and this happens if you are checking neither SSLPeer, nor SSLIssuer.

This does not mean that the connection is totally anonymous as Morag pointed out the certs will authenticate the connector. However the queue manager doesn't care as it will accept any connection where the signer chain is in the truststore and the cipherspec/ciphersuite matches the requirement!!!

Ad TRob often points out, in order to ensure that the connector is who he asserts to be, you need to check both the SSL PEER values (Distinguished Name of the cert) and the SSL Issuer's Distinguished Name
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
tczielke
PostPosted: Fri Jul 26, 2019 6:34 pm    Post subject: Re: SSL Encryption & Authentication using SVRCONNs Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

saurabh25281 wrote:
3. Is there any configuration that purely does encryption during transit but does not authenticate the client?


If I understand the question correctly, the answer would be yes and it would be a SVRCONN with SSLCAUTH(OPTIONAL) where the client end never presents a certificate. This would be a configuration where there is encryption and the client is not being authenticated. Maybe I am misunderstanding the question.
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Jul 26, 2019 7:04 pm    Post subject: Re: SSL Encryption & Authentication using SVRCONNs Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

tczielke wrote:
saurabh25281 wrote:
3. Is there any configuration that purely does encryption during transit but does not authenticate the client?


If I understand the question correctly, the answer would be yes and it would be a SVRCONN with SSLCAUTH(OPTIONAL) where the client end never presents a certificate. This would be a configuration where there is encryption and the client is not being authenticated. Maybe I am misunderstanding the question.

If you are really asking if you need SSL/TLS and certs to implement encryption, then, no. A 3rd party vendor who posts here regularly has a product that does that.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
tczielke
PostPosted: Tue Jul 30, 2019 4:59 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

fjb_saper wrote:
3)

Ad TRob often points out, in order to ensure that the connector is who he asserts to be, you need to check both the SSL PEER values (Distinguished Name of the cert) and the SSL Issuer's Distinguished Name


I would also add SERIALNUMBER in the SSLPEER as a good thing to check for authentication.

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.1.0/com.ibm.mq.sec.doc/q009830_.htm

Quote:
A serial number. This is a unique identifier assigned by the CA which issued the certificate. The serial number is unique within the CA which issued the certificate: no two certificates signed by the same CA certificate have the same serial number.

_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed Jul 31, 2019 9:24 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

tczielke wrote:

Quote:
A serial number. This is a unique identifier assigned by the CA which issued the certificate. The serial number is unique within the CA which issued the certificate: no two certificates signed by the same CA certificate have the same serial number.


Moot point if you're not checking the Issuer. As specified the Serial Number should be unique among the certs signed by the issuer. But so should also be the Distinguished Name.
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
tczielke
PostPosted: Thu Aug 01, 2019 4:19 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

fjb_saper wrote:
tczielke wrote:

Quote:
A serial number. This is a unique identifier assigned by the CA which issued the certificate. The serial number is unique within the CA which issued the certificate: no two certificates signed by the same CA certificate have the same serial number.


Moot point if you're not checking the Issuer. As specified the Serial Number should be unique among the certs signed by the issuer. But so should also be the Distinguished Name.


I personally would be cautious of using pieces of the Distinguished Name to guarantee uniqueness for the following reasons:

1) Not all CAs enforce unique DNs.
2) Even if they enforce unique DNs, are there ways around it by requesting one more DN attribute than the cert you want to impersonate, and match on all the other DN attributes?

The serial number is the X.509 specification way of identifying a certificate uniquely, and it seems like the most straight forward way to do that check for uniqueness of a cert, to me.
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Thu Aug 01, 2019 2:27 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

I hear you. I just thought I'd go easier on the maintenance. If you do your cert management well the new cert will have:
  • a new validity period
  • an new serial number
  • the same DN
  • the same issuer

And thus you could swap it without having to notify... but for you who will find the new serial number and reject it...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
tczielke
PostPosted: Sat Aug 03, 2019 7:35 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

fjb_saper wrote:
I hear you. I just thought I'd go easier on the maintenance. If you do your cert management well the new cert will have:
  • a new validity period
  • an new serial number
  • the same DN
  • the same issuer

And thus you could swap it without having to notify... but for you who will find the new serial number and reject it...


Yes, the certificate maintenance is more complicated with the serialnumber check. One option, is to check both serialnumber and DN pieces and then for a short period remove the serialnumber check during the maintenance period. There is also a certificate maintenance need to have MQ check for more than one certificate criteria for SSLPEER. Kind of like a namelist of SSLPEER checks. Certificate maintenance drives me crazy!
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
tczielke
PostPosted: Fri Sep 13, 2019 7:19 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

tczielke wrote:
fjb_saper wrote:
I hear you. I just thought I'd go easier on the maintenance. If you do your cert management well the new cert will have:
  • a new validity period
  • an new serial number
  • the same DN
  • the same issuer

And thus you could swap it without having to notify... but for you who will find the new serial number and reject it...


Yes, the certificate maintenance is more complicated with the serialnumber check. One option, is to check both serialnumber and DN pieces and then for a short period remove the serialnumber check during the maintenance period. There is also a certificate maintenance need to have MQ check for more than one certificate criteria for SSLPEER. Kind of like a namelist of SSLPEER checks. Certificate maintenance drives me crazy!


To add a few comments here, I realized after doing some research that with CHLAUTH it is possible to have multiple SERIALNUMBER checks for the same channel. So this allows an easy way to add in new certs and always have a SERIALNUMBER check, since you can have previously added in the CHLAUTH rule for the new cert/SERIALNUMBER and still have the rule for the current cert. I also realized with some recent testing that the Java client does not check for SERIALNUMBER, and there is an APAR being opened for that issue.
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Security » SSL Encryption & Authentication using SVRCONNs
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.