On Nov 12, 2010, at 10:42 AM, Toby Crawley wrote: > On 11/12/2010 10:26 AM, Jim Jagielski wrote: >> >> On Nov 12, 2010, at 10:04 AM, Toby Crawley wrote: >>> >>> If we suspect the source of the headers, we should suspect any data in the >>> request. If an entity can munge headers, it can munge anything else in the >>> request - the requests currently have no signing mechanism. If this type of >>> security is a concern, the deltacloud server should be accessed via https. >>> The client is based on RestClient, so should support https out of the box >>> if deltacloud is running with a valid certificate. If using a self signed >>> certificate, the client would probably need to be modified to not validate >>> the server cert, or given the CA for the server cert so it can validate. >> >> That's not 100% true. Sure, one can munge headers; it's trivial. But what if >> there is some simple md5 hash check, for example, related to the IP >> address of the client and some shared secret. The client IP, since it's >> NOT part of the http request, is not as easily munged... >> >> Any time you use http req headers as a control mechanism, you need >> some sort of a&a mechanism to provide oversight. Even something as >> simple a Digest auth (or some variant) provides *some* level of >> protection w/o the full overhead of ssl. >> >> Of course, it goes w/o saying, that I'm offering to *add* this >> capability ;) > > 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*
