On Thu, Oct 16, 2014 at 9:43 PM, Chris Custine <chris.cust...@gmail.com> wrote: > > 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. >
No, anyone on the network path in between the client and server can initiate this attack. https://www.openssl.org/~bodo/ssl-poodle.pdf and https://www.dfranke.us/posts/2014-10-14-how-poodle-happened.html has a lot more context on this but the interesting quote is: So if an attacker that controls the network between the client and the server interferes with any attempted handshake offering TLS 1.0 or later, such clients will readily confine themselves to SSL 3.0. Cheers, Niraj > > 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 >
