| Author |
Message
|
| Vitor |
 Posted: Mon Feb 23, 2015 11:29 am Post subject: Selective security on web services |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
IIBv9.0.0.2
RHEL 5.something
We have a perfectly happy set up where we have 1-n flows using HTTPS, with the key infrastructure as laid out in the InfoCenter and the keys signed by an internal CA. We are content because all the IIB sits behind walls of DataPower and other network appliances, and you couldn't see our IIB from the public internet with a telescope.
As part of the latest paranoid attempt to make my life complex, the site has recently decreed that no SSL shall be used; only TLS is acceptable. Again, we're talking about systems inside the walls not customers with web browsers; they at least are not my problem. Now using TLS with IIB is fine, but now I've been instructed to enforce this by refusing connections to SOAPInput nodes that don't use TLS. According to this, if I issue:
| Code: |
mqsichangeproperties PoorMisusedBroker -e DumpForDubuiousCode -o HTTPSConnecter -n sslProtocol -v TLS
|
then the default becomes TLS rather than SSL, but SSL is still allowed. A small amount of experimentation seems to confirm this.
I've attempted further research, and rapidly ended up to my waist in the IBM Java JSSE specification.
- Is there a simple way to turn off all non-TLS communication, i.e.:
| Code: |
mqsichangeproperties PoorMisusedBroker -e DumpForDubuiousCode -o HTTPSConnecter -n SSLAllowed -v false |
or
| Code: |
| mqsichangeproperties PoorMisusedBroker -e DumpForDubuiousCode -o HTTPSConnecter -n TLSOnly -v true |
- Is there a way to "sabotage" the broker's verification process so only TLS specs handshake correctly with the SOAPInput node? There's apparently no requirement to be nice, or return any helpful messages to the client, just to demonstrate that insecure cipher specs can't be used to connect to our end points.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Feb 23, 2015 11:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I would look for the technote/etc that described the relationship of IIB to the POODLE defect to see if there's a recommendation.
the only thing off the top of my head that I can think of is to set the ciphers to only allow TLS ciphers and not SSL ciphers. But that might still be exposed to POODLE. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 23, 2015 11:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| the only thing off the top of my head that I can think of is to set the ciphers to only allow TLS ciphers and not SSL ciphers. But that might still be exposed to POODLE. |
I don't think internally we're worried at this point about stray dogs; others here care about such things.
Do you have a link for how one would set the ciphers as you suggest?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 23, 2015 11:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 23, 2015 12:54 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
http://www-01.ibm.com/support/knowledgecenter/SSMKHH_9.0.0/com.ibm.etools.mft.doc/an09148_.htm
-n ciphers
Values? dunno.
presumably anything with TLS in it.
The point about POODLE is that I expect there are actually real instructions in whatever technote mentions it, to disable SSLV3. |
Bless you.
I actually knew that, and had a "Doh!" moment when I saw your link. I blame weather related brain freeze.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 23, 2015 12:59 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| I blame weather related brain freeze. |
Oh? is it cold where you are? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 23, 2015 1:09 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 23, 2015 1:23 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Vitor wrote: |
| I blame weather related brain freeze. |
Oh? is it cold where you are? |
Grrr........
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| paustin_ours |
| Posted: Mon Feb 23, 2015 1:33 pm Post subject: |
|
|
Yatiri
Joined: 19 May 2004
Posts: 667
Location: columbus,oh
|
| Quote: |
| A small amount of experimentation seems to confirm this |
can you shed some light on how to test this? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 24, 2015 5:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| paustin_ours wrote: |
| Quote: |
| A small amount of experimentation seems to confirm this |
can you shed some light on how to test this? |
I called a web service using a client that specified an SSLv3 rather than a TLS spec. Even with the property set to "TLS", the client sucessfully achieved a handshake and used the web service. The same client with a TLS spec worked, but failed with the property set to "SSL" (as expected).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Feb 25, 2015 12:32 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
|
|
