Re: Feedback on WebSocket API, Editor's Draft 13 November 2009.

On Fri, 4 Dec 2009, Sebastian Andersson wrote:
> On Fri, Dec 4, 2009 at 12:52, Ian Hickson <ian@hixie.ch> wrote:
> >> >> With flash, you can connect to any server and any port as long as 
> >> >> the application can first download a policy file from the same IP 
> >> >> number.
> >> >
> >> > Flash's security model has had so many security holes reported on 
> >> > it that I really don't want to try to emulate it. It also requires 
> >> > two sets of TCP connections per socket, and has some scary race 
> >> > conditions. It also requires talking to two different ports, which 
> >> > is dubious in shared hosting situations.
> >>
> >> In shared hosting situations, the policy file should be generated 
> >> from other data sources, just like other firewall rules, no?
> >
> > How is the client supposed to recognise a shared hosting situation?
> 
> It does not need to. It is an administrative issue of each site to 
> allocate hosts & port numbers to services and the policy file is the 
> site's way of telling what webpages are allowed to connect to them.

In a shared hosting situation, different ports on the same machine can be 
controlled by different users, so I don't see how this could work.


> >> Just so we are talking about the same thing. When the current flash 
> >> player tries to connect with TCP to a server, it first connects to a 
> >> different port on that server and gets a policy file in response, the 
> >> player does only have to open the port and the server just have to 
> >> send a file and close the socket afterwards. So it wastes less 
> >> network and server resources than getting the FavIcon.ico file for 
> >> example.
> >
> > There are at least two problems with this: first, the port contacted 
> > might not be the one under the control of the target service, and 
> > second, it means there are at least two TCP roundtrips required before 
> > the WebSocket connection can be opened.
> 
> How would the policy file and the service not be under the same control? 

In a shared hosting environment, typically port 80 is a virtual hosted 
HTTP server, and the ports above 1024 are under the control of the first 
user to bind to it. So ports 1024 and 1025 can be under the control of 
different users. If the policy file is served from port 1024, it can allow 
script on port 80 from one virtual host to access the service on port 1025 
intended for scripts of pages of another virtual host on port 80.


> > If we assume a round-trip time of 120ms, that means that opening a 
> > WebSocket connection takes 360ms rather than the 120ms it takes with 
> > the security model in the spec today. That's a lot of extra latency.
> 
> One could also do both connections at the same time, but not open the 
> socket to the application until the policy file has been read. Or simply 
> use a cache.

That seems more complex than necessary.


> >> I don't know if the current player caches the result, but that could 
> >> be added.
> >
> > Then you increase the race condition I mentioned from being merely a 
> > few milliseconds to being whatever the time-to-live of the policy file 
> > is.
> 
> Since I fail to see the attack scenario, I fail to see the race 
> condition.

The race condition is a separate issue. The race condition is what happens 
when the policy changes between the time that the policy file is read and 
the connection is established. Consider for instance the window between an 
error being found in a policy file and the policy being fixed. If the 
policy has a 24 hour time-to-live, then the site is automatically 
vulnerable for up to 24 hours for some users.


> >>> What's wrong with the way WebSocket does it?
> >> 
> >> Many custom protocols are based on a length field followed by a 
> >> protocol frame. With WebSocket it is possible to connect to such a 
> >> service and be connected for a while until a timeout happens and thus 
> >> a DoS attack against such a service would be trivial to write.
> >
> > Interesting. Do you have any examples of such services that I could 
> > study? If we could mitigate that that would be very useful. Are these 
> > services that send no traffic until they've received the first packet?
> 
> MS-RPC and CIFS are such I believe.

Interesting. I shall study these, thanks.


> At least one can send the example header from the RFC to them without 
> being disconnected nor getting an answer.

We may be able to do something about MS-RPC and CIFS specifically, but 
it's not clear that it's possible to have a general solution for the 
problem of servers that don't respond immediately, since in general 
they're indistinguishable from a slow network.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 5 December 2009 08:54:25 UTC