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 02:47, Ian Hickson <ian@hixie.ch> wrote:
> >> Although it is partly outside of the scope of the document, I still 
> >> would like to raise the question about why creating a new protocol 
> >> and not allowing plain TCP?
> >
> > It would be a security nightmare (e.g. it would mean a hostile Web 
> > site, when visited by a corporate user, could connect to an arbitrary 
> > HTTP server behind the intranet firewall and read its files).
> 
> I propose nothing (much) different than what is already available with 
> flash, so one is already exposed to the same problems.

Yes, and it's been a disaster. I'd rather make WebSocket more secure than 
Flash has been. :-)


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


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


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


> As far as I know there are two security problems with this model:
> a) the application can measure the time it takes to get the policy
> file and thus do port mapping. Skipping the two other ways of getting
> the policy file would solve this without limiting the usefulness much.
> I think this has been addressed in the latest version of the player by
> returning the error after the same amount of time.

This is kind of a moot point because you can do port scanning using <img> 
anyway.


> b) a naive implementation would use two different dns answers for the 
> two connections. This is an implementation issue more than a model 
> issue.

I hadn't thought of that one, that's a good point. As you say, this one is 
avoidable.


> >> The "origin" concept is a great way to limit malicious javascript, 
> >> but so is flash policy files. If a policy file must be downloaded 
> >> from a specific port/URL, before the application is allowed to 
> >> connect and the browser caches the result for a while that would 
> >> limit DoS attacks quite well while at the same time make the 
> >> WebSocket API powerfull enough to make use of old protocols.
> >
> > What's wrong with the way WebSocket does it?
> 
> The WebSocket protocol can not connect to any existing services and I 
> think that is a pretty serious drawback and limits its usefulness a lot.

That's actually the whole point of the protocol's handshake -- we don't 
want to make it possible to connect to existing services, since that would 
open the Web up to all kinds of problems. For example, at the moment, if 
someone screws up their security check and allows anyone to connect, the 
worst that can happen is that the service is exposed to other origins. A 
problem in intranet environments, certainly, but not really anything more 
than a DOS risk on the Web. However, if we allowed connection to existing 
services, a policy error could now result in a hostile site using the 
user's SMTP server, doing brute-force attacks on their intranet IMAP 
server, or accessing an IP-protected HTTP server, all significantly more 
serious security problems.


> The WebSocket protocol can be used to do portmapping.

So can <img>, even without script. That battle was lost years ago.


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

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

Received on Friday, 4 December 2009 11:53:11 UTC