Everett, not sure if I have one :) Anyway I think it should be
andreatu...@apache.org Thanks, Andrea On Fri, Oct 17, 2014 at 4:44 PM, Everett Toews <everett.to...@rackspace.com> wrote: > What’s your wiki.apache.org username? > > I just need to add you to https://wiki.apache.org/jclouds/ContributorsGroup > > Everett > > > On Oct 17, 2014, at 9:33 AM, Andrea Turli <andrea.tu...@gmail.com> wrote: > >> Everett, >> >> yeah no problem :) >> Actually I tried to edit that wiki page some time ago but I couldn't >> find my way, then I forgot to ask for help. >> >> Could you help me? >> >> Best, >> Andrea >> >> On Fri, Oct 17, 2014 at 4:26 PM, Everett Toews >> <everett.to...@rackspace.com> wrote: >>> Hi Andrea, >>> >>> Would you be willing to add yourself as the steward for Softlayer and >>> Docker on our Stewards [1] page? >>> >>> I don’t mean to put you on the spot but I wanted to throw it out there. >>> >>> Regards, >>> Everett >>> >>> [1] https://wiki.apache.org/jclouds/Stewards >>> >>> >>> On Oct 17, 2014, at 5:19 AM, Andrea Turli <andrea.tu...@gmail.com> wrote: >>> >>>> +1 (binding) >>>> >>>> * Executed the validation script: >>>> - Source code compiles and passes all tests >>>> - There are no RAT violations >>>> - Checksums match >>>> - Signatures match >>>> * All LICENSE and NOTICE files are correct >>>> >>>> * I ran also LiveTests for Docker and SoftLayer: >>>> - SoftLayer: >>>> Tests run: 154, Failures: 15, Errors: 0, Skipped: 10 >>>> - Docker (still on 1.0 version): >>>> Tests run: 38, Failures: 2, Errors: 0, Skipped: 26 >>>> >>>> For Docker *LiveTests: the provider needs a version bump, Docker >>>> continues to push new version out continuously, so the next release >>>> will have a best LiveTest coverage and will support latest Docker >>>> Engine. >>>> >>>> Cheers, >>>> Andrea >>>> >>>> On Fri, Oct 17, 2014 at 7:15 AM, Niraj Tolia <nto...@maginatics.com> wrote: >>>>> On Thu, Oct 16, 2014 at 10:04 PM, Chris Custine <chris.cust...@gmail.com> >>>>> wrote: >>>>>> >>>>>> On October 16, 2014 at 10:49:33 PM, Niraj Tolia >>>>>> (nto...@maginatics.com(mailto:nto...@maginatics.com)) wrote: >>>>>>> On Thu, Oct 16, 2014 at 9:43 PM, Chris Custine 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: >>>>>> >>>>>> This is the part that enables the exploit of SSL3, but this is not the >>>>>> actual exploit. >>>>>> >>>>>>> >>>>>>> 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. >>>>>> >>>>>> I understand that part, but this is just initiating the protocol >>>>>> downgrade. Downgrading to SSL3 isn’t really the issue, the issue is >>>>>> what is done to exploit that. They would still need to initiate many >>>>>> specifically formatted requests with varying path and body lengths from >>>>>> the *real* client to eventually resolve the encrypted attributes (from a >>>>>> jclouds standpoint this would probably be auth headers). This means >>>>>> that some part of the response from the actual endpoint would have to >>>>>> have some content that causes jclouds itself to go rogue and start >>>>>> making these orchestrated requests to nonsense urls, and with body >>>>>> content that is decremented to match the incrementing path, and do this >>>>>> many times (up to 256 times for each byte) until the server does not >>>>>> reject the SSL. If we have an flaw that allows execution of arbitrary >>>>>> script code of some variety in jclouds, then I am suddenly worried about >>>>>> a lot more than this exploit. :-) >>>>>> >>>>> >>>>> >>>>> Ah, I see better what you mean. Yes, from my understanding of POODLE, >>>>> there has to be some way for the attacker to be able to get jclouds to >>>>> generate URLs in the above scenario. We do not know all the ways in >>>>> which jclouds users use the library and if users can control the URLs >>>>> (say, for example, using a filename for upload that gets directly >>>>> encoded into the filename), I wonder if that is sufficient to launch >>>>> the attack. >>>>> >>>>> Cheers, >>>>> Niraj >>>>> >>>>> >>>>>> My 2 cents. >>>>>> >>>>>> Chris >>>>>> >>>>>> >>>>>>> >>>>>>> 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 >>>>>>>> >>>>>> >>> >
