Re: [hybi] Insight you need to know: Browsers are at fault when servers crash

Is it also possible that the client can be validated by virtue of it providing and using the nonce?

Given the nature of the protocol, the same key can be used to "randomize" the stream in both directions after the handshake.

This reduces the problem to the one where an attacker coerces the client into providing such a nonce (or having it appear so).  That requires control over the key parts of the handshake.

--Martin

p.s. This problem really needs a concrete mechanism at this stage.  Even an example or two might help.

> -----Original Message-----
> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of
> Scott Ferguson
> Sent: Monday, 26 July 2010 9:10 PM
> To: Maciej Stachowiak
> Cc: hybi@ietf.org
> Subject: Re: [hybi] Insight you need to know: Browsers are at fault
> when servers crash
> 
> Maciej Stachowiak wrote:
> > The difficulty is that the computation has to validate the HTTP-level
> handshake, looking at elements that cannot easily be forged, or it
> suffers from the same problem I described above. If it is derived
> solely from portions of the request that could be attacker-controlled,
> then it is predictable to the attacker, so using it as part of the
> crypto key for the body is no obstacle to injecting chosen plaintext.
> >
> But there are two separate validations: validating the client and
> validating the server. The same computation doesn't validate both at
> once. (It can't validate both at once, because the client validates the
> server but the server validates the client.)
> 
> Your proposed attack is the client-validation problem: is the client a
> real websocket client? (where the server is a websocket server.)
> 
> Adam's proposal is for the server-validation problem: is the server a
> real websocket server? (where the client is a websocket client.) It
> doesn't address the client-validation problem.
> 
> But it's not a flaw in Adam's proposal that it doesn't address the
> client-validation problem. It would only be a flaw if the attack showed
> a weakness in solving the server-validation problem.
> 
> (Just to be clear, it's not possible to have both issues in the same
> attack, because a non-websocket client talking to a non-websocket
> server
> isn't our problem.)
> > This means we'd need something with similar complexity to the current
> handshake, except we'd have the benefit that the first client -->
> server message can save a round trip.
> >
> The client-validation problem could be solved if there are elements in
> the initial request that cannot be forged, as you pointed out. For
> example, if the HTTP method cannot be forged, changing the HTTP method
> to something like "WEBSOCKET" would validate the client as a real
> websocket client.
> 
> If the entire request can be forged by a non-web-socket client, then
> you
> do need a second client response to the server's initial response. If
> the entire request can be forged, the server needs to send a random
> nonce and force the client to compute a hash to prove the client is a
> real client.
> 
> -- Scott
> > On the other hand, using your scheme straight-up without a prior HTTP
> header is probably safe without any additional rigidity.
> >
> > Regards,
> > Maciej
> >
> > _______________________________________________
> > hybi mailing list
> > hybi@ietf.org
> > https://www.ietf.org/mailman/listinfo/hybi
> >
> >
> >
> >
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi