incubator-deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toby Crawley <>
Subject Re: Dynamic selection of driver
Date Fri, 12 Nov 2010 15:42:53 GMT
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.


View raw message