OK, now I get where you're coming from.
If your T1 system only has an external CA's certs in the trust store, and your T2 system only has and internal CA's certs in its trust store, you eliminate the possibility, however remote, that both CAs could have signed 2 different certs with the same DN and if both CA certs were trusted on one system, that one system would not be able to distinguish between them for purposes of SSLPEER filtering.
Peter Potkay
-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Saturday, August 02, 2014 8:16 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ protocol over the internet and its pitfalls
Hi Peter,
I sort of did mean it. Any time you trust an additional CA, there's more certificates that pass validation. You then check the DN match, and eliminate things there.
But... if your internal certificate DNs aren't terribly obvious that they belong to you, maybe someone else could get a CA to sign a certificate that's the same as one signed by your internal CA.
Hopefully not very likely, but at least conceivable. My basic principle is to trust the minimal set of CAs possible for any QM.
Regards,
Neil Casey.
Post by Potkay, Peter M (CTO Architecture + Engineering)Neil,
The last sentence of your 1st paragraph implies to me that if you trust an external CA you can't securely lock your QM. With the granularity offered by SSLPEER, surely that's not what you meant. Or was it?
MQIPT is great...until something goes wrong, somewhere, and MQIPT is in the path so you have to trouble shoot it to implicate or vindicate it. I've found MQIPT's logs boggling - vulture threads?!
Peter Potkay
-----Original Message-----
Behalf Of Neil Casey
Sent: Friday, August 01, 2014 9:07 AM
Subject: Re: MQ protocol over the internet and its pitfalls
Hi Damian,
I was thinking of a separate port for each customer in MQIPT. That means that you can have a separate route definition, which gives you independent SSL configuration per customer. This means that you can have different trust settings and present different certificates to each customer if you need to. It also means that you don't have to trust the external CA in your core T3 queue manager, meaning that you can keep it locked securely only trusting your internal CA.
Although you can get close to this level of SSL validation using MQ v8, it only works if the client is running MQ v8 as well.
If you also have separate channels which match up with the ports, then you probably don't need separate listeners on MQ, just the separate ones in MQIPT.
MQIPT is a nice thing to have in T1, because it can terminate the SSL sessions in the proper place, and it shouldn't be that expensive. You don't need a license for it, so it is just the cost of a couple of (virtual) servers, and the load balancer configuration to allow either MQIPT instance to be used.
Regards,
Neil Casey.
Post by Costa, D. (Damian)Hi Niel,
Yes the IPT is something I proposed a long while back but it fell on deaf ears, under review again though.
Also assigning specific ports for each customer is a great idea. That would mean a MQ listener per incoming customer yes?
Message validation would in theory be run via a Datapower device if I had my way but like you said budget constraints can cause so many shortcuts to occur.
Is it possible to setup separate network interfaces from external and internal source? Would that help prevent intrusion at all ?
We'd also apply channel auth rules to all the inbound channels as well. check both IP and userid on the connection. Although if it's already hit our firewall the IP's would all look the Same after the address translation.
So T2 qmgr in a DMZ and T3 qmgr in the trusted Network where the actual work is done after all the security check points have successfully been passed.?
Thanks
-----Original Message-----
Behalf Of Neil Casey
Sent: 01 August 2014 01:01 PM
Subject: Re: MQ protocol over the internet and its pitfalls
Hi Damian,
If I had to implement this, I would be wanting MQIPT in T1. Set up
separate ports and svrconn channels for each client, and validate SSL certificates strongly.
Have a dedicated queue manager in T2, assigning limited capability
userids on the svrconn mcauser.
Having dedicated channels for each client allows you to limit the
number of concurrent channels that each one can create.
The T2 queue manager would in a perfect world run some sort of
message validation application, which would then pass the messages
through to the real application via channels to T3 queue managers.
This application would also be able to implement throttling or
shaping of the incoming message traffic to enforce SLA limitations,
and collect usage statistics for billing purposes. In practice, it
is possible that budget constraints would lead to configuration of direct forwarding to the T3 queue manager via QRemote or QAlias definitions.
Regards,
Neil Casey
On 1 Aug 2014, at 8:09 pm, Costa, D. (Damian)
Post by Costa, D. (Damian)HI all, just found out one of the projects that has a high profile want to use
MQ connectivity over the internet.
Post by Costa, D. (Damian)What pitfalls should we be wary of?
I'm guessing the clients will connect into our qmgr in a highly secure part of
our network but will still be via MQ client connections .
Post by Costa, D. (Damian)Thanks.
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email
is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are
provided in the Listserv General Users Guide available at
http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are
provided in the Listserv General Users Guide available at
http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES