| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQCE, SSL, MQ Advanced Message Security |
« View previous topic :: View next topic » |
| Author |
Message
|
| jfecq |
 Posted: Thu Mar 06, 2014 6:34 pm Post subject: MQCE, SSL, MQ Advanced Message Security |
 |
|
Apprentice
Joined: 24 Sep 2012
Posts: 36
|
Hi, I am quite confused between the 3.
SSL is to authenticate the queue manager connecting to each other via the certificates. SSL encryption encrypts messages ONLY on the channels between queue managers, and ensure the integrity while in flight.
I just came to know about MQCE and MQ Advanced Message Security. I am not sure the differences between the 2, and how are they different to SSL as well?
Can someone advise me on that? |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Thu Mar 06, 2014 7:15 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Do a bit of research on your own.
Go to google. Search for MQAMS. Search for MQCE. Search for SSL. Your questions will be answered there.
_________________
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 |
|
|
| jfecq |
| Posted: Thu Mar 06, 2014 7:39 pm Post subject: |
|
|
Apprentice
Joined: 24 Sep 2012
Posts: 36
|
| bruce2359 wrote: |
Do a bit of research on your own.
Go to google. Search for MQAMS. Search for MQCE. Search for SSL. Your questions will be answered there. |
Thanks for your kind reply. If you are able to provide any google result where the 3 are being compared, I will be greatly grateful. I would have thought failed to research is different from failed to understand what has been researched. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Mar 06, 2014 8:11 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Your disappointment is noted.
what is your skill set with MQ? What is your skill set with SSL? We can't begin preparing a research paper without knowing your level of understanding the basic concepts.
_________________
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 |
|
|
| jfecq |
| Posted: Thu Mar 06, 2014 8:38 pm Post subject: |
|
|
Apprentice
Joined: 24 Sep 2012
Posts: 36
|
You are saying I need to know SSL in depth to know how MQ make use of SSL? Like I need to understand SSL white paper to know that with SSL, messages are encrypted in channel?
Perhaps someone can correct my understanding below.
1) for MQCE and MQAMS, it is transparent to MQ clients. Message is encrypted when MQ API is called, and decrypted when when message arrives in the destination queue? So broker or application can start processing the message without decrypting?
2) when using FTE with MQCE and MQAMS, it is same as (1)?
What is the difference between MQCE and MQAMS then?
But I thought MQ clients can enable the SSL and specify the TLS with CipherSuite. Hence from the point where message is generated and put to destination queue with MQ client, the message is already encrypted? Until the point where message arrives in the destination queue, then it is decrypted? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Mar 06, 2014 9:17 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| jfecq wrote: |
| You are saying I need to know SSL in depth to know how MQ make use of SSL? Like I need to understand SSL white paper to know that with SSL, messages are encrypted in channel? |
No, I'm saying that you have been asked to do some research; and that you have merely asked us to do the research for you.
As we are non-paid volunteers here at mqseries.net, we expect that you will do basic research on your own. There is a wide variety of documentation on the three items.
| jfecq wrote: |
| What is the difference between MQCE and MQAMS then? |
Basic research means reading up on MQCE and MQAMS; then comparing and contrasting their capabilities and limitations.
_________________
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 |
|
|
| PaulClarke |
| Posted: Thu Mar 06, 2014 10:04 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
jfecq - the key difference between the technologies is whether the data is encrypted while it is at rest on a queue. So that is perhaps the first decision you need to make. Are you just interested in having the data encrypted while travelling over the network or do you also need the message data encrypted while it is just sitting in a local queue on your Queue Manager.
All 3 solutions will give you encrypted data across a channel but only MQAMS, as far as I know, will have the message data encrypted at rest. However there are a host of other differences such as performance, level of encryption, ease of use, complexity etc. So Bruce is right, it is worth reading up about all 3 before you make any decisions.
Regards,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| jfecq |
| Posted: Thu Mar 06, 2014 10:15 pm Post subject: |
|
|
Apprentice
Joined: 24 Sep 2012
Posts: 36
|
Thanks! I did read up but was confused that's why I seek help here.
http://www.capitalware.com/mqce_overview.html
| Quote: |
| The MQ Channel Encryption v3.0.0 (MQCE) is a solution that provides encryption for WebSphere MQ (WMQ) message data over WMQ channels. |
| Quote: |
| MQCE provides encryption for message data, which flows between WMQ resources. |
http://www-03.ibm.com/software/products/en/wmq-ams/
| Quote: |
| End-to-end, message-level security that offers data protection for your point-to-point messaging infrastructure. |
| Quote: |
| Application-level security protection that is easy to use. |
Which makes me wonder is it only at channel?
So if I have SSL for my channel, which the MQ clients can enable the SSL and specify the TLS with CipherSuite, it would seem that MQCE is not necessary. Whereas MQAMS will be a complement to SSL for message encryption?
OR, can I use SSL and MQCE together also, for compliance sake which need the message to be encrypted as well? |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Mar 07, 2014 1:26 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| jfecq wrote: |
| OR, can I use SSL and MQCE together also, for compliance sake which need the message to be encrypted as well? |
SSL (strictly speaking, TLS) invoked at MQ Client/MQ Server level provides for end-point authentication (to a certain degree) and encryption across the wire - it does not encrypt messages at rest in queues; MQCE does the same thing in regard to encryption across the wire, and to a degree authenticates end-points as each end-point would need the exit but again, it does not encrypt messages at rest. You would have to decide whether using a paid-for exit or inherently free TLS is a viable option for you - I would consider the two together to be somewhat paradoxical.
As regards AMS, that provides for encryption for messages at rest, so in theory (and I stress in theory) there is an argument for not using TLS encryption across the wire (why have the overhead of encrypting encrypted data?) and using end-point authentication only at the channel level.
_________________
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 |
|
|
| RogerLacroix |
| Posted: Fri Mar 07, 2014 2:11 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
Ok. Lets go over a few points first:
(1) MQ SSL is included with MQ but requires SSL certificates and is used to encrypt data as it passes over MQ channels (between 2 points only) i.e. data in flight
(2) MQCE is a Capitalware product that provides encryption for WebSphere MQ (WMQ) message data over WMQ channels. i.e. data in flight
(3) WMQ AMS is an IBM product that provides end-to-end encryption or application level encryption of message data. i.e. the message data is encrypted when the application does the MQPUT and is not decrypted until the receiving application performs an MQGET.
I created MQCE as a direct competitor to MQ SSL. Why, because MQ SSL is messy and requires a LOT of manual effort by the MQAdmin.
Major Features of MQCE:
- Easy to set up and configure (unlike SSL)
- No application changes required
- Can be configured as either queue manager to queue manager or client application to queue manager solution
- All message data flowing over a channel will be encrypted (nothing missed or forgotten)
- Secure encryption/decryption methodology using AES with 128, 192 or 256-bit keys
- Standard MQ feature, GET-with-Convert, is supported
- Provides high-level logging capability for encryption / decryption processing
- Cost is $299.00 (cheaper in volume) per queue manager plus 15% yearly maintenance and support fee
Here are some MQ SSL disadvantages:
- SSL Certificates must be purchased YEARLY at a cost of roughly $400 USD.
- SSL certificates expire, requiring regular repurchase, renewal and then the MQAdmin needs to deploy the SSL certificates.
- There is no logging capability to see who accessed which queue manager.
- This form of security is only as secure as the integrity of the client side certificates. Anyone who possesses a copy of the certificate will have full access (It is extremely easy to copy a keystore on a Windows Server).
- SSL is Node-to-Node security and NOT End-to-End security. Node-to-Node security that any application running on the server can connect to the queue manager. It is far better to control each application that is connecting to a queue manager (i.e. End-to-End).
Configuration / Management:
- When a customer purchases MQCE license(s), they get permanent MQCE license keys that do NOT expire.
- SSL Certs expire yearly. If you forgot to update a queue manager's SSL Cert and it expires then your channels stop working.
If an MQAdmin has 100 queue managers, how much wasted time do they spend YEARLY, just to update each queue manager's SSL Cert?
| jfecq wrote: |
| If you are able to provide any google result where the 3 are being compared, I will be greatly grateful. |
You cannot compare WMQ AMS to either MQ SSL or MQCE. Its like comparing a bicycle to a car. Just because both have wheels does not make them similar. You can only can compare MQ SSL to MQCE as I did above.
Now stepping sideways, I created an umbrella product called: MQ Enterprise Security Suite (MQESS) to originally compete against IBM's WMQ Extended Security Edition (WMQ ESE) which IBM revamped and updated to WMQ AMS. MQESS is simply 3 Capitalware products (MQAUSX, MQCE & MQME) in 1 and costs $100 less than purchasing the 3 individually. You can read more about MQESS at http://www.capitalware.com/mqess_overview.html
Now if you want a comparison of Capitalware's MQESS and IBM's WMQ AMS then go to: http://www.capitalware.com/rl_blog/?p=409
Hopefully that helps.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| tczielke |
| Posted: Sat Mar 08, 2014 6:26 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
Hi Roger,
That's very interesting what you laid out as the differences between MQCE and the standard SSL/TLS encryption specifications. If I am inferring correctly, MQCE would not be required to send the encryption algorithm plain text between the client and server (i.e. the two queue managers)? Based on my understanding, that is one of the main weaknesses of the SSL/TLS specification. During the SSL/TLS handshake, the encryption algorithm is negotiated (plaintext, I believe) between the client and server. This means a "man-in-the-middle" knows the encryption algorithm that will be used in the data exchange. It is just a matter of time before a parallel brute force attack can break the encryption. If you get very lucky and guess right, you can break it instantly. However, if you are using an encryption tool that does not need to negotiate the encryption algorithm because that was pre-configured between the two end-points, I definitely see the security benefit there. The "man-in-the-middle" hacker has no knowledge of how you are encrypting the data.
Thanks,
Tim |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Sat Mar 08, 2014 8:16 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| tczielke wrote: |
| If I am inferring correctly, MQCE would not be required to send the encryption algorithm plain text between the client and server (i.e. the two queue managers)? Based on my understanding, that is one of the main weaknesses of the SSL/TLS specification. |
No. None of that is true. You need to read up on encryption methodologies.
(1) ALL encryption algorithms are well known, published and available as open source.
(2) The 2 end points do NOT transmit the algorithm but rather encrypted data.
(3) For SSL, the sender uses the public certificate of the receiver to encrypt the data and the receiver uses its private certificate to decrypt the data
(4) MQCE uses a unique PassPhrase (secret sauce) for each message it transmits. The PassPhrase is made up from pieces of connection session and message being sent that both the sender and receiver known.
| tczielke wrote: |
| This means a "man-in-the-middle" knows the encryption algorithm that will be used in the data exchange. |
No. "man-in-the-middle" (MITM) attack is:
- someone faking they are the receiver and giving the sender a fake public certificate
- the MITM connects to the receiver and gets receivers public certificate
- the sender encrypts the data with the fake public certificate
- the MITM decrypts the data, saves it and then encrypts the data with the receiver's public certificate and sends the message to the receiver
- the receiver decrypts the message not knowing about the MITM
| tczielke wrote: |
| It is just a matter of time before a parallel brute force attack can break the encryption. If you get very lucky and guess right, you can break it instantly. |
That has absolutely nothing to do with "man-in-the-middle" (MITM) attacks. Please go and read about brute force attacks at http://en.wikipedia.org/wiki/Advanced_Encryption_Standard it takes a very long time.
| tczielke wrote: |
| if you are using an encryption tool that does not need to negotiate the encryption algorithm because that was pre-configured between the two end-points, I definitely see the security benefit there. |
No again. Sure you can pre-configure MQCE to use the same PassPhrase for all messages sent over the channel but I do NOT recommend it because it is a VERY bad idea. This would allow a hacker to send same and different messages and determine what the PassPhrase is.
MQCE defaults to auto-PassPhrase which means it will generate a unique PassPhrase for every message and is what I recommend to all customers.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| tczielke |
| Posted: Sat Mar 08, 2014 8:54 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
Hi Roger,
Just to clarify, I am talking about the encryption algorithm exchange that happens in the first part of the SSL/TLS handshake. Based on my reading (ex. SSL and TLS Designing and Building Secure Systems by Eric Rescorla), the first part of the SSL handshake is for the client and server to negotiate what encryption algorithm they will use. The client sends a list of algorithms that it supports, and then the server chooses from one in the list and sends back the agreed upon alogrithm. My understanding is that this is done in plain text as no encryption has been started at this point between the client and server.
The "man-in-the-middle" was more of a generic reference for someone that is in the middle of the data exchange between the client and server and can snoop the SSL/TLS handshake. For example, he/she has the ability to snoop on a router between the client and server.
Also, I disagree that a highly parallel brute force attack is not a feasible way to drastically reduce the time it takes to break the encryption into a reasonable time frame. Parallelism allows you to break the brute force approach into a much less time intensive approach. For example, you can take the entire permutations of your key, divide that into 1,000,000 distinct subsets, and have 1,000,000 parallel brute force attacks happening at the same time against each subset. The approach to further increase that division of subsets is only limited to your computer resources. At least, this is how I see it.
Thanks,
Tim |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Mar 08, 2014 8:39 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Moving to security forum
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Mar 08, 2014 9:47 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| tczielke wrote: |
| Just to clarify, I am talking about the encryption algorithm exchange that happens in the first part of the SSL/TLS handshake. Based on my reading (ex. SSL and TLS Designing and Building Secure Systems by Eric Rescorla), the first part of the SSL handshake is for the client and server to negotiate what encryption algorithm they will use. The client sends a list of algorithms that it supports, and then the server chooses from one in the list and sends back the agreed upon alogrithm. My understanding is that this is done in plain text as no encryption has been started at this point between the client and server. |
What you describe is in the very beginning stages of the SSL "handshake." Knowing or exchanging the names of the encryption and hashing algorithms is not a security exposure.
You need to continue reading, paying close attention to what happens in the subsequent steps that lead to a secure conversation.
_________________
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 |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
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
|
|
|
|
