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

On Dec 6, 2010, at 10:44 PM, Mark Nottingham wrote:

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

Indeed, we do, and they result in something that is reasonably HTTP-compatible, enough that you could make a two-way server. 
> 
> 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.

Adam and Eric's proposal basically does what you say, except that it doesn't designate a new port for WebSocket traffic, and it makes a small nod towards letting servers and server-side infrastructure dispatch between WebSocket and HTTP on the same port. I am not sure it would simplify things much to abandon those goals.

If the goal was not to interoperate with HTTP at all, it would be much better to use an approach where everything is encrypted. One plausible way to do that would be to restrict the protocol to TLS-only, at which point the nextprotoneg proposal can take care of dispatch without having to involve the HTTP layer. I think this is a plausible option, but many hybi WG members have expressed concern about the performance issues and other barriers to deployment of an all-TLS solution.

Another approach is to invent our own crypto and start with a key exchange. Inventing crypto makes me nervous compared to using something known (such TLS), and might well impose many of the same costs that folks are worried about with TLS.

It's also worth noting that operating over ports 80/443 and coexisting with an HTTP server are goals that come from our charter and requirements document, so abandoning those goals would likely require a major reboot of the group. We already have implementors impatient to see a production-shippable protocol, it doesn't seem so great to me to go back to the drawing board.

Regards,
Maciej

Received on Tuesday, 7 December 2010 07:05:38 UTC