Re: [hybi] Redesigning the Web Socket handshake

[Justin Erenkrantz <[e-mail]>]

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.

> 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.  (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 - 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.

My $.02.  -- justin