POODLE

[Adrian Cole <ad...@gmail.com>]

All:

This is becoming quite the amateur security parade with regular FUD
and incorrect facts. I've given a lot of breadcrumbs, as like many of
you, we deal with this in other projects, if not our day job. Here's a
recap, intentionally not on the 1.8.x thread as that was and is a
terrible place for discussion.

Recap:

POODLE is a man-in-the-middle attack which requires both ends to talk
SSLv3. It is a protocol bug, which means updating to a new version
isn't going to help. It is a man-in-the-middle because it requires
such a position to trigger a fallback to SSLv3. There are generally 2
ways out for those vulnerable.
1. Disabling SSLv3 at either the server or the client side.
2. Mitigate the downgrade part of the attack with TLS_FALLBACK_SCSV
http://googleonlinesecurity.blogspot.com.au/2014/10/this-poodle-bites-exploiting-ssl-30.html

This attack isn't easy, and won't affect all java apps. Man in the
middles for things like this are most typically discussed as the
attacker running javascript in a browser. Take a look at this which
discusses how hard this is, ex 1000s of connections under control.
http://blog.erratasec.com/2014/10/some-poodle-notes.html#.VEb9voBdWIk

jclouds:

jclouds already has a man-in-the-middle configuration, which
materializes as "untrusted" when people use the property
"jclouds.trust-all-certs". Yes, jclouds interferes with TLS here, but
seriously.. this is not a configuration meant for those interested in
security!

jclouds by default *does not* interfere with the default SSL
configuration of the JVM in normal course. Therefore, if someone via
changing the the default url handler or the default ssl socket factory
will impact jclouds. This includes disabling poodle via means
including restricting the ciphers.

Regardless:

Eventhough the attack vector is far fetched from most JVM scenarios,
many folks will want to disable SSLv3.

What to do:

First is to tell them the truth about jclouds. That is that in the
current default code, it *inherits* the ssl socket factory
configuration, which is the place SSLv3 can be disabled.

Second is to ask ourselves whether to support advanced configuration,
such as a curated list of fallback. Ex. TLSv1.2, then 1.1. etc. This
is a big discussion as it *widens the scope* of jclouds to now
actually include TLS config! Doing so will need further updates, for
example when TLSv1.3 is out. plus extra testing. I highly recommend
exposing http drivers directly and punt to them. jclouds can have the
same default it has now, which is to use the inherited SSL socket
factory from the JVM. As most have proven we aren't security experts,
I recommend we stick to that. In apachehc, netty, etc, allow users to
configure objects that are documented in their apis. Basically, I
highly recommend we don't dig ourselves a new place of maintenance
that very few are experienced enough to review.

Finally, we do have things like FGCP and AzureCompute which muck with
SSL. We should take this lesson and see if we can support that without
having to now be responsible for things like the next POODLE. This has
lost more time in idle discussion or fear-thrashing than some
providers took to write. We have stake in steering clear of things
like this when looking into how to support providers that need to do
more with ssl.

-A

Re: POODLE

[Adrian Cole <ad...@gmail.com>]

Clarification:

This was a general comment to everyone including me, not one to
Diwaker. I only copied him in as he was the last emailer on the
release thread.

My "amateur security parade with regular FUD and incorrect facts"
comment was not about Diwaker, it was about us as a whole.

We didn't engage security experts, we spread fear uncertainty and
doubt in the release, and also completely misread our own code (not
even code I wrote I might add!).

At the end of the day, we thrashed about on a scenario as unlikely to
affect java deployments as POODLE yet this returns nada eventhough we
literally wrote a bash script assembly tool!

http://markmail.org/search/?q=jclouds+shellshock

Long story short, this isn't me shooting the messenger, and if by
copying him I implied that, I apologize to everyone, especially
Diwaker.

That said, I clearly intended to rattle the cage we are in. If we want
to take security seriously, we have a long way to go. Self-inflicted
release delay isn't the best way to accomplish that. WRT TLS, I think
it best we do what we can to get out of the way of it, and leave that
to the people who already have that responsibility (ie. authors of JVM
and http drivers roll their own sockets).

I hope this at least clarifies my intent.
-A


On Tue, Oct 21, 2014 at 6:04 PM, Adrian Cole <ad...@gmail.com> wrote:
> All:
>
> This is becoming quite the amateur security parade with regular FUD
> and incorrect facts. I've given a lot of breadcrumbs, as like many of
> you, we deal with this in other projects, if not our day job. Here's a
> recap, intentionally not on the 1.8.x thread as that was and is a
> terrible place for discussion.
>
> Recap:
>
> POODLE is a man-in-the-middle attack which requires both ends to talk
> SSLv3. It is a protocol bug, which means updating to a new version
> isn't going to help. It is a man-in-the-middle because it requires
> such a position to trigger a fallback to SSLv3. There are generally 2
> ways out for those vulnerable.
> 1. Disabling SSLv3 at either the server or the client side.
> 2. Mitigate the downgrade part of the attack with TLS_FALLBACK_SCSV
> http://googleonlinesecurity.blogspot.com.au/2014/10/this-poodle-bites-exploiting-ssl-30.html
>
> This attack isn't easy, and won't affect all java apps. Man in the
> middles for things like this are most typically discussed as the
> attacker running javascript in a browser. Take a look at this which
> discusses how hard this is, ex 1000s of connections under control.
> http://blog.erratasec.com/2014/10/some-poodle-notes.html#.VEb9voBdWIk
>
> jclouds:
>
> jclouds already has a man-in-the-middle configuration, which
> materializes as "untrusted" when people use the property
> "jclouds.trust-all-certs". Yes, jclouds interferes with TLS here, but
> seriously.. this is not a configuration meant for those interested in
> security!
>
> jclouds by default *does not* interfere with the default SSL
> configuration of the JVM in normal course. Therefore, if someone via
> changing the the default url handler or the default ssl socket factory
> will impact jclouds. This includes disabling poodle via means
> including restricting the ciphers.
>
> Regardless:
>
> Eventhough the attack vector is far fetched from most JVM scenarios,
> many folks will want to disable SSLv3.
>
> What to do:
>
> First is to tell them the truth about jclouds. That is that in the
> current default code, it *inherits* the ssl socket factory
> configuration, which is the place SSLv3 can be disabled.
>
> Second is to ask ourselves whether to support advanced configuration,
> such as a curated list of fallback. Ex. TLSv1.2, then 1.1. etc. This
> is a big discussion as it *widens the scope* of jclouds to now
> actually include TLS config! Doing so will need further updates, for
> example when TLSv1.3 is out. plus extra testing. I highly recommend
> exposing http drivers directly and punt to them. jclouds can have the
> same default it has now, which is to use the inherited SSL socket
> factory from the JVM. As most have proven we aren't security experts,
> I recommend we stick to that. In apachehc, netty, etc, allow users to
> configure objects that are documented in their apis. Basically, I
> highly recommend we don't dig ourselves a new place of maintenance
> that very few are experienced enough to review.
>
> Finally, we do have things like FGCP and AzureCompute which muck with
> SSL. We should take this lesson and see if we can support that without
> having to now be responsible for things like the next POODLE. This has
> lost more time in idle discussion or fear-thrashing than some
> providers took to write. We have stake in steering clear of things
> like this when looking into how to support providers that need to do
> more with ssl.
>
> -A