On Mon, Mar 30, 2009 at 5:28 PM, "Plüm, Rüdiger, VF-Group" <[email protected]> wrote: > > >> -----Ursprüngliche Nachricht----- >> Von: Paul Querna >> Gesendet: Montag, 30. März 2009 17:18 >> An: [email protected] >> Betreff: Re: [PROPOSAL] mod_cloudbeat >> >> On Mon, Mar 30, 2009 at 5:10 PM, "Plüm, Rüdiger, VF-Group" >> <[email protected]> wrote: >> >> -----Ursprüngliche Nachricht----- >> >> Von: Paul Querna >> >> Gesendet: Montag, 30. März 2009 17:04 >> >> An: [email protected] >> >> Betreff: Re: [PROPOSAL] mod_cloudbeat >> >> >> >> On Mon, Mar 30, 2009 at 4:45 PM, Jim Jagielski >> >> <[email protected]> wrote: >> >> > >> >> > On Mar 29, 2009, at 11:43 AM, Paul Querna wrote: >> >> >> >> >> >> URL Authentication is done by computing an randomly seeded >> >> md5 signature >> >> >> of: >> >> >> seed + "$"+ MD5(seed + shared_secret + uri) >> >> >> This is base64 encoded, and placed in a >> 'X-Cloudbeat-Auth' header. >> >> >> >> >> > >> >> > Thinking outloud here... The idea I think is to ensure that >> >> > the X-Cloudbeat-Auth defines an authenticated server, using >> >> > the fact that it knows the shared secret. But how does the >> >> > above do that? Say for example that A and B known to each >> >> > other and B is sending X-Cloudbeat-Auth. This is easy to >> >> > find out, of course. So I setup B' to send the exact same >> >> > header and apply a DoS to B causing it to drop/hang/whatever. >> >> > Won't A just see B' as B, maybe thinking that it had a >> >> > momentary glitch and came back? It seems to me that we need >> >> > some sort of IP:port knowledge in there as well. >> >> >> >> In my mind, URL includes the IP/port, so you shouldn't be >> able to DoS >> >> it this way. I guess I should of been clearer by what I meant with >> >> URL. >> >> >> >> I was thinking about this more, and we should also change >> the hash to >> >> sha1, considering it only takes a few days to find md5 >> collisions if >> >> you have enough playstation 3s: >> >> seed + "$"+ sha1(seed + shared_secret + ip ":"+ port + URI) >> > >> > Which IP do you use here? The one from the client that >> sends the request? >> > Furthermore we should include a timestamp as we are very >> vulnerable against >> > replay attacks otherwise. >> >> Server A wants to talk to B. >> >> We include server B's IP in the hash that Server A sends to B. (this >> prevents B without knowledge of the secret from doing a replay). > > But it doesn't prevent A' that sniffed the traffic from A to B to replay. > OTOH why fiddle with this auth stuff anyway. We could make it save by > using TLS and client certs.
bleh, just trying to avoid massive configuration hurdles to get a system up and running, by for the most part trying to just avoid man in the middle protection :(
