On Wed, Feb 3, 2010 at 12:20 AM, Maciej Stachowiak <mjs at apple.com> 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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.