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

[Scott Ferguson <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>
>
>
>