Re: [hybi] Handshake was: The WebSocket protocol issues.

[Maciej Stachowiak <[e-mail]>]

On Sep 27, 2010, at 10:25 PM, Willy Tarreau wrote:

> On Tue, Sep 28, 2010 at 10:30:14AM +1000, Greg Wilkins wrote:
>> On 28 September 2010 09:26, Scott Ferguson <[e-mail]> wrote:
>>> Greg Wilkins wrote:
>>>> 
>>>> Scott,
>>>> 
>>>> yes - I glossed over the details of what the actual hash should be in
>>>> the ping packet.  I believe H(c-nonce, "WebSocket") is a good hash
>>>> that indicates the server is a WS.
>>> 
>>> That's not quite the issue. It's the second hash in the PONG that's missing,
>>> because we also need to verify the client as a WS client and not a hijacked
>>> HTTP client (or hijacked future non-websocket client):
>> 
>> OK, I've got it.
>> 
>> For your proposal of a server nonce, then a HELLO op-code is more
>> appropriate than ping/pong as the pong should normally contain the
>> same content as the ping.
>> 
>> So my proposal was:
>> 
>> HTTP(upgrade,nonce)   -->
>> <-- HTTP(101)
>> <-- WS(ping,hash(nonce,"WebSocket"))
>> [ <-- * WS(op, data)  ]
>> --> WS(pong,hash(nonce,"WebSocket"))   ; client calls onOpen
>> [ * WS(op, data) -->  ]
>> 
>> 
>> Your amendment is
>> 
>> HTTP(upgrade,c-nonce)   -->
>> <-- HTTP(101)
>> <-- WS(hello,hash(c-nonce,"WebSocket"),s-nonce)
>> [ <-- * WS(op, data)  ]
>> --> WS(hello,hash(s-nonce,"WebSocket"))   ; client call onOpen
>> [ * WS(op, data) -->  ]
>> 
>> 
>> I'm not 100% convinced that the server nonce is really necessary, as
>> the client has already been validated by sending Sec-Headers and the
>> upgrade in the first place, and the contents of the ping message must
>> be copied into a pong message (and is not predictable if the nonce is
>> hidden from the client).
> 
> I really think that if we can get a clean WS-based handshake, we can
> get rid of the Sec-* headers, as the WS handshake will validate a much
> more serious part of the protocol than the HTTP headers with their
> tricks.

If we go with an HTTP-based handshake at all, we have to keep something in the original HTTP request that browser-hosted HTTP clients are assumed unable to send. Otherwise we'll significantly increase the risk of HTTP-vs-WebSocket cross-protocol attacks.

Regards,
Maciej