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

[Maciej Stachowiak <[e-mail]>]

On Jul 26, 2010, at 3:52 AM, Adam Barth wrote:

> On Mon, Jul 26, 2010 at 12:37 PM, Maciej Stachowiak <[e-mail]> wrote:
>> On Jul 26, 2010, at 3:16 AM, Adam Barth wrote:
>>> On Mon, Jul 26, 2010 at 11:45 AM, Maciej Stachowiak <[e-mail]> wrote:
>>>> On Jul 26, 2010, at 12:39 AM, Adam Barth wrote:
>>>>> You can also this this idea at the end
>>>>> of an HTTP-like handshake to get started sending data without waiting
>>>>> for the server to reply.
>>>> 
>>>> Doesn't this second design make WebSocket services potentially vulnerable to
>>>> cross-protocol attacks from HTTP? It's easy for the HTTP attacker to make up
>>>> a key and encrypt the attack payload with it, unless the server has to prove
>>>> it understands WebSocket based on part of the handshake that the in-browser
>>>> HTTP attacker can't control before it is allowed to process messages.
>>> 
>>> I don't quite follow.  You seem to be worried about the WebSocket
>>> server being attacked by a non-WebSocket client.  How does that relate
>>> to whether a WebSocket client waits for the server to acknowledge?
>> 
>> The current design requires the server to fairly thoroughly validate the handshake before it is even possible for it to process messages. A previous design made it easy for the server to ignore the handshake and just start processing messages. If the key for decoding messages is in the HTTP body, or any part of the request that could plausibly be controlled by an attacker, then we are back to that earlier state where it is much easier to accidentally write a vulnerable server. If the key appears in HTTP headers, then some amount of "rigidity" may be required to make it hard to forge it with a non-WebSocket HTTP request.
> 
> Ah, I understand.  We're worried about the consequences of common bugs
> in server implementations.  One approach is to use whatever value the
> server would have sent back to the client to verify that the server
> understood the handshake as part of the key for decrypting the body.
> That way the server is forced to do the same computation, we're just
> verifying it's correctness cryptographically.

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.

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.

On the other hand, using your scheme straight-up without a prior HTTP header is probably safe without any additional rigidity.

Regards,
Maciej