| Author |
Message
|
| MQ_Lover |
 Posted: Fri Nov 15, 2013 6:53 am Post subject: SSLPEER value for a client |
 |
|
Acolyte
Joined: 15 Jul 2013
Posts: 67
|
Hi MQ SSL Experts,
I need some clarification regarding SSLPEER value, we have in Production environment a MQ SVRCONN channel where it has SSLPEER value set but at the application end which looks to be JMS config they have informed they haven't set any SSLPEER value, I am just wonering is that possible? means if we enable on the channel SSLPEER value but the application doesn't at their end? then how does MQ match? it is it from the cert it checks the DN value and gets it from their? |
|
| Back to top |
|
 |
| JosephGramig |
| Posted: Fri Nov 15, 2013 1:21 pm Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
Correct, it is matching what is in SSLPEER to what is in the cert issued to the client.
If they (JMS Client) specify SSLPEER, that is going to be matched to what is in the DN of the cert that belongs to the QMGR (server).
It's a question of who is checking whom for what. If you put OUs in the SSLPEER, the order matters (look this up in the Info Center).
In this case, somebody has determined it is not good enough that the client has been issued a valid SSL cert, but more information needs to be used to determine the validity of the use of the channel.
Why do you need to do this?
Well, the client can present any ID they want with a valid SSL cert and the Qmgr has no way to know that without some additional information. |
|
| Back to top |
|
|
| MQ_Lover |
| Posted: Tue Dec 03, 2013 6:17 am Post subject: |
|
|
Acolyte
Joined: 15 Jul 2013
Posts: 67
|
Hi JosephGramig,
Thanks for the response, your are right with a valid SSL cert and DN value copied anyone can use that, but the client is not third party it is internal within the bank hence their are not much chances for fraudelent use here, thanks for clarifying.
Cheers |
|
| Back to top |
|
|
| rammer |
| Posted: Tue Dec 03, 2013 6:28 am Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
| MQ_Lover wrote: |
| it is internal within the bank hence their are not much chances for fraudelent use here |
I thought most fraud came within... |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Dec 03, 2013 6:35 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQ_Lover wrote: |
| the client is not third party it is internal within the bank hence their are not much chances for fraudelent use here |
Your bank must have a significantly more laid back security & audit function than this one! Please advise what medication they're using (officially or unofficially) & I'll see what I can do to get it into the water supply...
Seriously, there are 2 broad points you should consider:
Don't assume everything inside your bank system is supposed to be there. No external protection system is invunerable and you shouldn't trust applications just because they're running inside your DMZ
A huge percentage of bank frauds are committed by or with the assistance of inside help. Weak controls inside your system just help them.
(This is not to say that a huge percentage of bank employees are frausters. The vast bulk of these hard working people are honest & reliable, the rest are management and me.)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Dec 03, 2013 8:30 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| MQ_Lover wrote: |
| ...but the client is not third party it is internal within the bank hence their are not much chances for fraudulent use here... |
I suspect that your internal and external auditors might disagree with this statement. I suspect further that there is bank policy that differs with this position.
_________________
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 |
|
|
| JosephGramig |
| Posted: Tue Dec 03, 2013 8:34 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
imho, unless you use SSL and map the certificate to an ID on the machine where the Qmgr is running, you have no meaningful security implementation.
Yes, you might have used exits instead but I'm going to ignore exits for now.
Your first line of defense is always the firewall.
Next, it is how you have implemented security within WebSphere MQ. |
|
| Back to top |
|
|
| rammer |
| Posted: Tue Dec 03, 2013 8:36 am Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
Whats wrong with the old trusted method. Head in Sand and Fingers Crossed...  |
|
| Back to top |
|
|
|
|
