ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Security » MQ, SSL and the POODLE attack

Post new topic  Reply to topic Goto page 1, 2  Next
 MQ, SSL and the POODLE attack « View previous topic :: View next topic » 
Author Message
PeterPotkay
PostPosted: Mon Oct 20, 2014 8:43 am    Post subject: MQ, SSL and the POODLE attack Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

http://www-01.ibm.com/support/docview.wss?uid=swg21687433&myns=swgws&mynp=OCSSFKSJ&mync=E

Among other things listed in this technote:
Quote:
Environment variable GSK_PROTOCOL_SSLV3=OFF should also be set in all MQ environments on UNIX, Linux and Windows platforms

_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
zpat
PostPosted: Mon Oct 20, 2014 11:46 pm    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Tue Oct 21, 2014 12:16 am    Post subject: Reply with quote

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
View user's profile Send private message
zpat
PostPosted: Tue Oct 21, 2014 12:29 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Tue Oct 21, 2014 1:03 am    Post subject: Reply with quote

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
View user's profile Send private message
zpat
PostPosted: Tue Oct 21, 2014 1:36 am    Post subject: Reply with quote

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
View user's profile Send private message
smdavies99
PostPosted: Tue Oct 21, 2014 2:01 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Oct 21, 2014 5:15 am    Post subject: Reply with quote

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
View user's profile Send private message
PeterPotkay
PostPosted: Tue Oct 21, 2014 5:31 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Tue Oct 21, 2014 5:37 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Tue Oct 21, 2014 6:15 am    Post subject: Reply with quote

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
View user's profile Send private message
PeterPotkay
PostPosted: Tue Oct 21, 2014 7:00 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Oct 21, 2014 7:01 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Tue Oct 21, 2014 7:31 am    Post subject: Reply with quote

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
View user's profile Send private message
tczielke
PostPosted: Wed Oct 22, 2014 11:01 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » IBM MQ Security » MQ, SSL and the POODLE attack
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.