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.
Toby
