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

On Dec 6, 2010, at 6:13 PM, Mark Nottingham wrote:

> 
> On 07/12/2010, at 12:30 PM, Maciej Stachowiak wrote:
> 
>> On Dec 6, 2010, at 4:53 PM, Mark Nottingham wrote:
>> 
>>> I don't think that's the relevant aspect here. "Another port" could be port 80 or port 443 (nasty, and you wouldn't make it the default, but I think you see where I'm going). 
>>> 
>>> The question is why it's necessary to run both HTTP and WebSockets traffic over the *same* port simultaneously -- something that AFAICT is taken as axiomatic, and I'm really wondering why.
>> 
>> Web developers will likely want to operate both a WebSocket service and an HTTP service on the same server, since WebSocket services are likely to be most useful in combination with a Web application that makes use of them. At the same time, they will want their WebSocket traffic to go through firewalls properly. It would be a significant burden if a WebSocket service required a separate domain name, physical or virtual server, and possibly SSL cert.
>> 
>> Thus desire to have a single piece of server software that can dispatch connects to HTTP applications or Web applications as appropriate.
> 
> You don't need a different domain name, hardware, OS instance or certificate to listen to a different port, and if you have a wildcard SSL cert, you can use the same cert for the same port number on two different hosts. 
> 
> E.g., someone who doesn't want to buy a separate cert can listen to:
> 
> myhost.example.com:80 <-- http traffic
> myhost.example.com:443 <-- websockets traffic*
> 
> Someone writing a more involved application that needs HTTP-over-SSL as well can do:
> 
> myhost.example.com:80 <-- http traffic
> myhost.example.com:443 <--- https traffic
> websockets.example.com:443 <--- websockets traffic
> 
> ...by either using their existing wildcard cert, or buying a new one (where the cost is approaching zero).
> 
> The problems you point out are, on the server side, trivial to address and nearly non-issues; all of the current approaches seem like way-overengineered premature optimisation. Since you generally can't count on the same process (or box, or even colo, in many architectures) handling two requests from the same client, there isn't any benefit to having them in the same address space, and as already discussed, it adds significant complexities for server-side implementers. 

I could nitpick your deployment scenarios (I believe they would increase barriers to deployment), however, I wonder what this approach is meant to gain us. 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.

Regards,
Maciej

Received on Tuesday, 7 December 2010 06:17:26 UTC