| Author |
Message
|
| PeterPotkay |
 Posted: Mon Oct 20, 2014 8:43 am Post subject: MQ, SSL and the POODLE attack |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
 |
| zpat |
| Posted: Mon Oct 20, 2014 11:46 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
The sounds of knees jerking is becoming loud already....
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Oct 21, 2014 12:16 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| zpat wrote: |
| The sounds of knees jerking is becoming loud already.... |
It's not knees jerking so much as having to tick yet another 'security' box - brought to you by the same people that insist on 'on the wire' encryption, but glaze over when you tell them 'but I can read the messages at rest on the queue'.
_________________
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 |
|
|
| zpat |
| Posted: Tue Oct 21, 2014 12:29 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Yes, but the risk of breaking internal systems through premature changes (which are supposed to help security) is far higher than the risk of someone with access to the internal network, choosing this moment to exploit this complex vulnerability (and ignoring many easier ways to cause damage - like taking an axe to my head!).
For example my IIB web admin over https has just stopped working from my firefox browser as it's been nobbled by disabling SSLv3... 
I can switch back to IE for now, but then IE 9 doesn't work properly with many of IIB web admin features. Still I suppose it keeps me busy.
On that subject, I suppose the way to fix it is to change the SSLProtocol setting on the IIB web admin HTTPS connector? We don't set SSLv3 on it - so I assume that must be the default?
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Oct 21, 2014 1:03 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| zpat wrote: |
| Yes, but the risk of breaking internal systems through premature changes (which are supposed to help security) is far higher than the risk of someone with access to the internal network, choosing this moment to exploit this complex vulnerability (and ignoring many easier ways to cause damage - like taking an axe to my head!). |
Since when has corporate security been about the realities and less about being seen to do something?
_________________
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 |
|
|
| zpat |
| Posted: Tue Oct 21, 2014 1:36 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Yes, but when IBM recommend it as well - game over....
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Oct 21, 2014 2:01 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| zpat wrote: |
For example my IIB web admin over https has just stopped working from my firefox browser as it's been nobbled by disabling SSLv3...
|
Which is why I keep a portable version of firefox V24 ESR jst for accessing the broker web U/I on my network. It never goes outside so can't be subject to Poodle. And does not get updated!!!!!
Then when I get the chance, I'll D/L the latest version of portable V24 ESR and use that to sort out the access using a non SSL (i.e. TLS) connection if it is possible.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 21, 2014 5:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| zpat wrote: |
| The sounds of knees jerking is becoming loud already.... |
It's not knees jerking so much as having to tick yet another 'security' box - brought to you by the same people that insist on 'on the wire' encryption, but glaze over when you tell them 'but I can read the messages at rest on the queue'. |
And don't understand why you start crying because you've implemented AMS to deal with this, and the security people are abolishing the use of "software & application level SSL" because they're updating the network to use wire level encryption "which meets all the appropriate security criteria".
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Oct 21, 2014 5:31 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Since this thread has shifted towards WMB / IIB, and IBM hasn't yet sent out anything for WMB/IIB as it relates to POODLE....
The default for the SOAPRequest Node is TLS, and you have to specifically ask for something older like SSL v3 or v2. But the HTTPRequest Node is opposite and its default is SSLv3.
So it looks like developers of messages flows have to validate what settings they use on these nodes, unless IBM comes out with some environmental variable that the WMB/IIBM admin can set to disable SSL v2/v3 across the whole Broker.
_________________
Peter Potkay
Keep Calm and MQ On
Last edited by PeterPotkay on Tue Oct 21, 2014 7:01 am; edited 1 time in total |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 21, 2014 5:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Presumably both of the request nodes will auto-negotiate up to a higher level of encryption if the producer end doesn't support anything other than TLS.
The larger concern is making sure that the *Input nodes, or more realistically their associated HTTP listeners, are not vulnerable to attacks via POODLE.
There are associated SSL properties on the listeners that can be set.
Or, one reason I have continued to advocate that everyone front end their Brokers with a separate web server... |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Oct 21, 2014 6:15 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| exerk wrote: |
| zpat wrote: |
| The sounds of knees jerking is becoming loud already.... |
It's not knees jerking so much as having to tick yet another 'security' box - brought to you by the same people that insist on 'on the wire' encryption, but glaze over when you tell them 'but I can read the messages at rest on the queue'. |
And don't understand why you start crying because you've implemented AMS to deal with this, and the security people are abolishing the use of "software & application level SSL" because they're updating the network to use wire level encryption "which meets all the appropriate security criteria". |
I admire your optimism, but unfortunately the bean counters go a bit pale when the mention of proper tools to do the job come up in the discussion, and AMS isn't as sexy as corporate box ticking it seems 
_________________
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 |
|
|
| PeterPotkay |
| Posted: Tue Oct 21, 2014 7:00 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mqjeff wrote: |
Presumably both of the request nodes will auto-negotiate up to a higher level of encryption if the producer end doesn't support anything other than TLS.
|
I think the auto negotiating works its way down thru the older protocols, not up to the newer ones. So if the SSL client (the WMB request node in this case) is configured to start with SSL v3, its only use that or go older to SSL v2.
The HTTP Request Node defaults to SSL v3.
http://www-01.ibm.com/support/knowledgecenter/SSKM8N_8.0.0/com.ibm.etools.mft.doc/ac04595_.htm
| mqjeff wrote: |
The larger concern is making sure that the *Input nodes, or more realistically their associated HTTP listeners, are not vulnerable to attacks via POODLE.
There are associated SSL properties on the listeners that can be set.
|
Fortunately the default protocol on the HTTP listeners in WMB is TLS (according to the WMB 8 K.C). You have to explicitly ask for SSL. So likely this won't be to big an impact as WMB when acting as the SSL Server by default uses TLS.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 21, 2014 7:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| Vitor wrote: |
| exerk wrote: |
| zpat wrote: |
| The sounds of knees jerking is becoming loud already.... |
It's not knees jerking so much as having to tick yet another 'security' box - brought to you by the same people that insist on 'on the wire' encryption, but glaze over when you tell them 'but I can read the messages at rest on the queue'. |
And don't understand why you start crying because you've implemented AMS to deal with this, and the security people are abolishing the use of "software & application level SSL" because they're updating the network to use wire level encryption "which meets all the appropriate security criteria". |
I admire your optimism, but unfortunately the bean counters go a bit pale when the mention of proper tools to do the job come up in the discussion, and AMS isn't as sexy as corporate box ticking it seems |
Well how am I supposed to implement AMS intercepters without SSL to authenticate users???? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Oct 21, 2014 7:31 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| exerk wrote: |
| Vitor wrote: |
| exerk wrote: |
| zpat wrote: |
| The sounds of knees jerking is becoming loud already.... |
It's not knees jerking so much as having to tick yet another 'security' box - brought to you by the same people that insist on 'on the wire' encryption, but glaze over when you tell them 'but I can read the messages at rest on the queue'. |
And don't understand why you start crying because you've implemented AMS to deal with this, and the security people are abolishing the use of "software & application level SSL" because they're updating the network to use wire level encryption "which meets all the appropriate security criteria". |
I admire your optimism, but unfortunately the bean counters go a bit pale when the mention of proper tools to do the job come up in the discussion, and AMS isn't as sexy as corporate box ticking it seems |
Well how am I supposed to implement AMS intercepters without SSL to authenticate users???? |
MQ chicken, Security egg ... or is it the other way around?
_________________
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 |
|
|
| tczielke |
| Posted: Wed Oct 22, 2014 11:01 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
I ran across this when doing research for POODLE. If anyone disagrees with the assessment, please let me know. I am not an encryption expert!
It sounds like there are other valid security reasons to move from RC4, but one thing I have just become aware of is that it looks like RC4 is not susceptible to POODLE because it is not a CBC based cipher.
http://security.stackexchange.com/questions/70719/ssl3-poodle-vulnerability
https://www.imperialviolet.org/2014/10/14/poodle.html
So it does look like there are MQ SSL v3 ciphers (i.e RC4_MD5_US) that are not susceptible to POODLE.
Please note, I am not trying to refute the recommendation of the IBM MQ security bulletin on POODLE. I just thought this extra piece of information was worth knowing for the other MQ administrators out there. |
|
| Back to top |
|
|
|
|
