I am hoping others can confirm this, but after reading the advisory and several commentaries on it, I can’t think of any way that this exploit can affect a jclouds client. My interpretation is that in addition to the man in the middle requirement to force the protocol downgrade to SSL3 and subsequent packet modification, the exploit also requires some injection of code onto the client that will cause the client to execute repeated requests to an endpoint with an incrementing http path length and decrementing body length.
I don’t see any opportunities to inject random script code into a jclouds client and have it execute in a way similar to javascript in a browser, and from what I have read, that is what it would take to make use of this exploit. Hopefully other will have the opportunity to interpret this and weigh in with their insight as well. Thanks, Chris -- Chris Custine On October 16, 2014 at 6:20:23 PM, Andrew Phillips (aphill...@qrmedia.com(mailto:aphill...@qrmedia.com)) wrote: > > I prefer to exercise an abundance of caution and extend the vote until > > we understand the issue. > > I wasn't planning to close the vote until we have more details on > this, indeed. Obviously, the more people can help have a look at this, > the better ;-) > > PR at https://github.com/jclouds/jclouds/pull/575 > > Thanks! > > ap
