On Fri, 2010-11-12 at 12:07 -0500, Jim Jagielski wrote: > On Nov 12, 2010, at 11:44 AM, Toby Crawley wrote: > > > On 11/12/2010 10:54 AM, Jim Jagielski wrote: > >> > >> On Nov 12, 2010, at 10:42 AM, Toby Crawley wrote: > >>> Yes, ssl is not the only solution, but adds end to end security over the > >>> entire request, without adding complexity to the deltacloud code. I don't > >>> see a deltacloud service getting enough traffic to justify worrying about > >>> ssl overhead, and I would be more worried about someone extracting my > >>> cloud credentials, or munging the actual request itself than altering the > >>> driver or endpoint headers. > >>> > >> > >> So it's either "trust nothing" or "trust everything"? :) Methinks that > >> there's > >> a middle ground somewhere in there *grin* > >> > > > > Sure, there is a middle ground. My point is that if someone has the ability > > to munge my headers, then they have access to my cloud credentials, which > > is a much larger problem IMO. > > > > Agreed. But that is hardly something totally unique in the HTTP > space. My point is that if http headers will be used for control, > then unless we have some sort of checks on them, then *only* > ssl will be an option to enable some sort of trust value > associated with that. > > Is that a long-term, viable condition?
Deltacloud doesn't trust the user - it doesn't care either way ;) But in a serious production deployment, SSL should be used to protect the HTTP basic auth header that the client uses to send its credentials for the backend cloud. David
