Re: [hybi] Redesigning the Web Socket handshake

[Maciej Stachowiak <[e-mail]>]

On Feb 2, 2010, at 6:44 PM, Jamie Lokier wrote:

> Maciej Stachowiak wrote:
>> Did anyone really say that? Isn't mod_pywebsocket a proof that it is in fact possible: <http://code.google.com/p/pywebsocket/>?
> 
> Curious: Is it compliant?  I.e. does it reject requests which aren't
> matching the exact octets needed, and create a response which does
> match the exact octets needed?

I don;t actually know. Note that the spec does not require

> 
> Or does it just work without being WebSocket spec compliant?
> 
>> As far as I can tell, the WebSocket spec does not require special
>> hardcoded handling of the request handshake. It's totally allowed to
>> run it through a normal HTTP stack. In fact, it's totally allowed
>> for servers to do no checking of the client request handshake at
>> all, but that creates a security hole (possibility of violating
>> integrity of a WebSocket service with XDomainRequest, cross-site XHR
>> or cross-site form submission), one of the security holes we are
>> trying to fix.
> 
> Is it permitted to not check the client request and be WebSocket spec compliant?
> (Not just work, but be able to claim compliance.)

As far as I can tell, yes.

> 
>> FWIW I think my nonce proposal would allow doing this for the
>> response at no cost in security - getting your victim to echo back a
>> hash of an unpredictable nonce is so unlikely that there's no need to
>> count on newlines in the handshake.
> 
> hash(nonce) + regular HTTP would go through proxies.
> 
> Current proposal intentionally fails at compliant HTTP proxies, on port 80,
> doesn't it?

I think they would still fail because of the upgrade request. 

> (I'm wondering why the CORS check used for XmlHttpRequest is
> unsuitable, though.)

I think CORS might have a potential weakness too. But not quite the same as the vulnerabilities I'm worried about. WebSocket won't start transmitting actual messages until it sees the handshake, while XHR will transmit the message body without checking for an HTTP response first. However, it can only send cross-site what you can already send with forms, so it does not open any new attack surface.

> 
> Maybe we can take the nonce idea further: An "are you a WebSocket
> server that supports subprotocols X,Y,Z that I must have" check, where
> a WebSocket server that doesn't support X,Y,Z would fail it.  That'd
> be infinitely more reliable than HTTP's Expect mechanism, which relies
> on proactive implementation by server developers who sometimes don't,
> making it unusable.
> 
> If you like that idea, I'll describe how it would work.

I'm not sure I fully understand it from your description.

Regards,
Maciej