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
