Re: [hybi] Redesigning the Web Socket handshake

[Maciej Stachowiak <[e-mail]>]

On Feb 3, 2010, at 7:38 AM, Justin Erenkrantz wrote:

> On Wed, Feb 3, 2010 at 12:20 AM, Maciej Stachowiak <[e-mail]> wrote:
>> I asked a security expert to review this and he had two suggestions:
>> 1) Include the nonce hash in the status line. The strongest protection
>> against cross-protocol attacks comes in the first few bytes, according to
>> him, so it should be as early as possible.
> 
> The drawback with doing it in the reason is that it is going to be
> substantially harder to trust that HTTP/1.1 clients and such get
> proper access to the reason.  (And, again, relying upon any bits in
> the reason is a violation of HTTP - the reason is *only* intended for
> human eyes.  I've seen hands slapped by Roy many times when folks try
> to expect that the reason is machine-parsable.)  Due to that, I think
> it's an acceptable tradeoff to just put it in the header as originally
> suggested.  It will likely still be in the first packet that the
> client receives.

The goal is more like "first few bytes" than "probably first packet". Remember, we're trying to defend against cross-protocol attacks, so what well-behaved clients and servers will do is not super relevant. I am more concerned with the security of the protocol than pleasing the aesthetic sense of HTTP gurus.

> 
>> 2) The hash should also include the request origin and some fixed
>> WebSocket-specific string (e.g. "WebSocket::"). (He actually suggested 'HMAC
>> the string "Web
>> Socket::" and origin of WebSocket request using the nonce as a key' but I'm
>> not sure if he was serious.)
> 
> Using the origin IP introduces a lot of problems when there are
> reverse proxies involved.

The origin is not an IP address. I'm talking about what goes in the WebSocket-Origin header. See the spec for an explanation and examples.

>  (Since it seems that prior discussions have
> belittled NATs and transparent forward proxies as not being
> "relevant", I'll set those aside - but I feel the implementation
> challenges are just as relevant there too.)  Try as some might to
> fight against it, we should simply realize that most large-scale WS
> deployments are going to see some type of reverse proxy sitting in
> front of it.  Therefore, the server generating the nonce probably
> won't know the origin easily

The nonce is actually generated by the client, not the server. I assume you mean the hash (produced from the nonce among other things). But see above. This doesn't relate to IP addresses.

> - and will have to rely upon custom
> information set by its reverse proxy in front of it to generate the
> proper nonce.  On the server-side, knowing the "real" origin IP is a
> very error-prone process and probably would give us more grief due to
> naive server implementations getting it wrong than we really intend.
> There is no HTTP standard for setting the origin IP on the hops, but
> most big sites end up setting some custom header out of necessity, but
> I expect many basic deployments do not do so.

 - Maciej