| Author |
Message
|
| magkids |
 Posted: Wed Aug 15, 2007 8:41 pm Post subject: self-signed certificate + one-way authentication |
 |
|
Newbie
Joined: 09 Aug 2007
Posts: 8
|
| I wonder using self-signed certificate and one-way authentication can solve my situation instead of using mutual authentication. I do not need to authenticate the identity of each unique users. As long as the user holding the server self-signed certificate, he can gain access to queue manager. If I keep the server self-signed certificate in some secure database, then one-way authentication is already sufficient. Is this okay for my situtation? Thanks. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Aug 15, 2007 11:58 pm Post subject: Re: self-signed certificate + one-way authentication |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| magkids wrote: |
| Is this okay for my situtation? Thanks. |
How can we know how secure you want your system? 
But consider this. If a "valid" user holds a self-signed certificate against the server, how do you control the distrubition of that certificate? If Alice is given a certificate to access Bob, can Mallory obtain it? Or spoof it?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| magkids |
| Posted: Thu Aug 16, 2007 12:18 am Post subject: |
|
|
Newbie
Joined: 09 Aug 2007
Posts: 8
|
Sorry for any unclearance.
My situation is like this. In my company, there is currently no any security on access to MQ. With firewall, external users can not access our internal domain network. So what we want is just prevent any non-MQ developers from access the MQ. (want to increase security from zero to a bit)
Back to the question, instead of giving the cert for user to create its keystore and import the cert, I want to save the keystore in a secure database. So everytime the user connect to MQ, it will connect to the database to get keystore and password. Just assume they will not give the keystore (holding only self-signed server certificate) and password to others, is it okay that only those can access to the secure database can gain access to MQ? Thanks |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 16, 2007 12:33 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
If all you're trying to do is lock out non-MQ people, why not use MQ security to authorise the MQ group(s) & deauthorise everyone else? That's got to be easier than distributing certificates & setting up databases.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| magkids |
| Posted: Thu Aug 16, 2007 12:48 am Post subject: |
|
|
Newbie
Joined: 09 Aug 2007
Posts: 8
|
authorize seems to be of no use for Java applications.
For java applications, IBM is up to the developer to set the correct MQMD.UserID value. i.e. by setting the Java code as: MQEnvironment.userID = "FRED".
That means even if i m non-mq group people, I can specify MQEnvironment.userID = "mqmAdmin", and use that identity to access MQ.
So just setting authorize for mqm group is not okay. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 16, 2007 1:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| magkids wrote: |
That means even if i m non-mq group people, I can specify MQEnvironment.userID = "mqmAdmin", and use that identity to access MQ.
So just setting authorize for mqm group is not okay. |
Not a Java person personally, but that does seem like a bit of an oversight. All you need to do to gain admin rights is one line of code; one wonders how the MQ admins in all the Java sites round the world sleep at night. Unless they all have SSL. Very strange. I'd have thought that the actual, autheticated user the Java was running as would have needed set context authority to do that, but what do I know? In the case of Java, very little!
Your solution seems broadly similar. Instead of setting this line, the non-MQ person needs to obtain/spoof this certificate which isn't hard. MQ will access the database, determine that the certificate is valid (which it would be) and grant access on that basis. So it doesn't sound like you're that much further forward.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| magkids |
| Posted: Thu Aug 16, 2007 2:06 am Post subject: |
|
|
Newbie
Joined: 09 Aug 2007
Posts: 8
|
| Vitor wrote: |
Not a Java person personally, but that does seem like a bit of an oversight. All you need to do to gain admin rights is one line of code; one wonders how the MQ admins in all the Java sites round the world sleep at night. Unless they all have SSL. Very strange. I'd have thought that the actual, autheticated user the Java was running as would have needed set context authority to do that, but what do I know? In the case of Java, very little!
|
Actually I was read from this http://www.mqseries.net/phpBB2/viewtopic.php?t=17842
Even though I set the MCAUser and set the authorities of the MCAUser, I can not restrict the access of non-mqm group, so I must use exit or SSL. Provide that we want free solution and not want developers to write program, so choose SSL.
| Vitor wrote: |
Your solution seems broadly similar. Instead of setting this line, the non-MQ person needs to obtain/spoof this certificate which isn't hard. MQ will access the database, determine that the certificate is valid (which it would be) and grant access on that basis. So it doesn't sound like you're that much further forward. |
User who need to access MQ need to hold the server-cerficate, this certificate is keep in database, if I set the access to database in secure, and assume they will not give out the certificate to others publicly, so this provide a basic security. The chance that hacker exist within company is low, so we would eliminate the risk of spoof the certifiate[/url] |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 16, 2007 2:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
That thread is 3 years old & refers to v5.3.0!
I'm still surprised that (especially in this modern day and age with auditors all over the place) it's true but my lack of Java knowledge is a matter of record on this board.
| magkids wrote: |
| assume they will not give out the certificate to others publicly, so this provide a basic security. The chance that hacker exist within company is low, so we would eliminate the risk of spoof the certifiate |
Both of those are risks I'd not get away with on this site: the first assumption falls on the fact that such resources are passed round development & test teams like candy; in the second instance I'd not be concerned by an external or malicious hacker but a well meaning internal user attempting to bypass controls to speed up some activity and blundering round as an MQ admin.
But it's your system and whatever works for you (and your auditors) is clearly the right solution.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Aug 16, 2007 3:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The issue with Java security still holds - because it still holds true that pure Java code can't access the OS user registry and the MCA still defaults to using it's authority when the passed in user is null.
There are changes in the v6 Java client that help the situation a bit, but not a lot.
The nice thing about the MCAUser is that (at least after applying the APAR that prevents you from bypassing MCAUser) it doesn't matter if all the developers have the cert or not - they still can only do the things that the MCAUser can do.
Storing the cert in a database isn't going to help a lot. Users will need to export the cert from the database, and import it into a local iKeyman key database. This keydb can then be freely passed around.
So the question still remains - is this secure enough for your situation?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 16, 2007 4:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jefflowrey wrote: |
The issue with Java security still holds - because it still holds true that pure Java code can't access the OS user registry and the MCA still defaults to using it's authority when the passed in user is null.
|
I'll bear this problem in mind. Once (if!) I get past "Hello World" Java applets. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Aug 16, 2007 1:20 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
|
| Back to top |
|
|
| magkids |
| Posted: Thu Aug 16, 2007 5:47 pm Post subject: |
|
|
Newbie
Joined: 09 Aug 2007
Posts: 8
|
Thanks all. The two risk are out of my boss consideration as he does not need to consider such high security.
To RogerLacroix, thanks for your advice, but we do not want to consider any pricing product. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Fri Aug 17, 2007 8:03 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| magkids wrote: |
| Thanks all. The two risk are out of my boss consideration as he does not need to consider such high security. |
Since anyone can create a self-signed certificate, this will not give you the little bit of security you are looking for.
| magkids wrote: |
| want to increase security from zero to a bit |
You cannot get a 'bit of security'. It is black or white. Either you have a secure environment or not.
| magkids wrote: |
| To RogerLacroix, thanks for your advice, but we do not want to consider any pricing product. |
Not a problem. Some people (Admins / Managers / Directores) do not value their business transactions or information.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Aug 17, 2007 2:44 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| RogerLacroix wrote: |
| magkids wrote: |
| Thanks all. The two risk are out of my boss consideration as he does not need to consider such high security. |
Since anyone can create a self-signed certificate, this will not give you the little bit of security you are looking for. |
Presumably not everyone is able to install that certificate in the queue manager's key ring.
Presumably not everyone is able to alter the channel to allow it to accept a given certificate.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| supreeth |
| Posted: Sat Aug 18, 2007 4:48 pm Post subject: |
|
|
Voyager
Joined: 17 May 2005
Posts: 90
Location: London
|
Hi,
I was watching this post and truly the situation is funny  when they don't care about security, why even try for a bit well, I was wondering ... even if configuration is done for mutual authentication and for argument's sake ... even if certificates are signed by a CA ... how hard is it for me to pass on my certificate to some one else ... Even though SSL helps us go one step further in security model ... it may not completely secure us atleast with the way MQ is designed. Thats the reason many firms go in with security exits at any cost even after having SSL. They would use SSL mainly to encrypt the data exchange. Atleast in the MQ world ... no one blindly trusts CA signed certificates too ... guys ... would be glad to accept if anyone thinks otherwise and would want to make any ammendments to my statements.
well, magkids ... was thinkin of a cost-effective and simple solution to ur issue and I can only think of someone writing a simple security exit ... which would check for the user's IP address and substitute the MCAUSER to a user which has the reqd permissions ... This simple exit should be very easy to write and should be available for use within maximum of 3 days. BTW ... this solution would help if the number of people in ur group are not in thousands ... which i assume would not be the case by look of things. You can have the list of ur developer IP addresses in a config file ... which the security exit can use for matching/verifying.
Let me know if this solution woks for u ... i can even send u a sample template which u can enhance to ur reqmt ...
cheerz!!!
supreeth
_________________
Supreeth Gururaj
IBM Certified WMQ Solution Expert |
|
| Back to top |
|
|
|
|
