Re: [hybi] workability (or otherwise) of HTTP upgrade

[Mark Nottingham <[e-mail]>]

On 07/12/2010, at 5:16 PM, Maciej Stachowiak wrote:
> Even if declare that WebSocket is not "meant to" be served by the same origin server as HTTP, we still have the following issues:
> 
> - We don't want WebSocket to be usable to attack an HTTP origin server. Even if WebSocket connects are not "meant to" go to an HTTP server, an attacker can still choose to do this, so we must defend against this scenario.
> - We don't want WebSocket to be usable to attack an HTTP intermediary. The attacks described by Adam and Eric do not depend on the concept that a network protocol is meant to go to an HTTP server, indeed, attacks are possible with Java sockets and Flash sockets, which don't care at all what kind of server is at the other end.
> - We don't want WebSocket servers to be easily attackable using HTTP clients built into Web browsers, since we have learned from HTTP's history of cross-protocol attacks and are responsible enough to avoid creating the same kinds of problems.
> - If WebSocket was blatantly incompatible with HTTP, the good folks of the IETF would probably not be happy about using it over port 80.
> 
> I think this ends up putting us in the same basic design space that we've already been discussing for the WebSocket protocol, even if we don't think it is a recommended setup to serve WebSocket and HTTP from the same port on the same host at the same time. In fact, even if we don't recommend using WebSocket over port 80, as long as the in-browser client lets Web applications choose the port, most of the above issues arise.
> 
> About the only simplification from this kind of scheme would be that we don't have to care about making it easy for infrastructure to dispatch between WebSocket and HTTP. We'd just have to make sure HTTP servers will bail early.

These are all absolutely still concerns, but we have proposals for addressing them. 

The difference is that we wouldn't have to figure out how to make it safe *and* compatible with the existing HTTP infrastructure; we wouldn't have to catch all of the accidental / deployment issues as well as the active attacks.

That would make the way forward fairly simple:

1) Designate a new port for Websockets traffic
2) Allow that to be overridden (much as with HTTP and pretty much every other protocol) for people who have immediate deployment considerations (i.e., they'll use 443)
3) Design the protocol so that it can't spoof other protocols, by using a selection of techniques:
  a) Exchanging a nonce, with HMAC response
  b) Armouring each message 
  c) Encrypting the whole damn thing
*without* the pretence that it's HTTP.

I'm sure (3) is an oversimplification and/or just plain wrong, but that's why we have Adam. #1 gives us a long-term safe deployment strategy, whereas #2 lets the impatient deploy right away, and also gives a fallback if #1 doesn't take off in the long run.

Cheers,

--
Mark Nottingham   http://www.mnot.net/