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

On Sun, 31 Jan 2010, Sebastian Andersson wrote:
> On Sat, Jan 30, 2010 at 10:31, Ian Hickson <ian@hixie.ch> wrote:
> > Right now, today, if I were to expose a WebSocket service on my 
> > Dreamhost shared server, I could do so without any trouble. If we used 
> > a scheme such as the one described above using a policy file, anyone 
> > else also hosting their site on the same server could grant access to 
> > my server to their scripts on their page. Whether this is a technical 
> > or administrative issue, it's an issue we have to handle today.
> 
> If you only allow the policy file from being read from a single port

How would we do that?


> > IMHO, yes. I understand that security is a tradeoff between risk and 
> > reward, but fundamentally, it seems to me that it is far off the 
> > "risk/reward" scale to design a system in such a way that a security 
> > problem cannot be fixed when it is discovered. Having the user agent 
> > cache the security policy and act on that cached version even after a 
> > security problem has been found prevents security problems from being 
> > fixed in a timely manner.
> 
> Sure, it would cause a downtime

We should not design our protocol in such a way that a configuration 
mistake in a security policy can only be fixed by forcing downtime on 
existing users.


> With the Web Socket protocol:
> - Existing services would have to be changed if they should be
> accessible (with the risk of bugs, duplication of existing access
> control and logging).

This is intentional, to prevent pages from abusing existing services.


> -- This is a huge total cost and a huge potential for security problems.

I think this massively overstates the risks.


> - Requires all new services to implement the policy mechanism correctly.

It's pretty trivial to implement.


> -- Instead of just having a few correct implementations in the clients 
> (that already have code for origin handling and whose designers 
> hopefully are aware of the problems), each server will have to have it 
> with associated risks of errors. A huge potential for new security 
> problems. Will of course be cheaper and less risky when libraries are 
> available for most languages, but still many more implementations.

I don't understand. Why would the servers have it? It's the client that 
enforces the security policy.


> - Native clients against a new service would have to use the Web
> Socket protocol too.

If it's a Web Socket subprotocol... then yes. I wouldn't recommend that 
people use this protocol for designing protocols intended to be used by 
native clients other than browsers, though obviously that's possible too.


> -- Adds a little extra cost and risks. Will of course be cheaper and
> less risky when libraries are available for most languages, but still
> way more implementations.

Than what? I'm confused. Web Socket is really trivial to implement -- the 
whole point is to make it easy to implement so anyone can do it. It's like 
CGI, intended for anyone to be able to hack something up quickly.


> What about someone adding support for Basic authentication in their 
> client, exposing the credentials?

I don't understand this point. What does the Web Socket protocol have to 
do with how you design your subprotocol's authentication?


> - One can't prevent a client from connecting to a port that it should 
> not be allowed to connect to, but the client can't start communications.

No idea what that means.


> -- Yet another DoS vector, but as you've written, there are others so
> then it is ok?

It's not another DOS vector, it's the same DOS vector. You already have to 
handle it. If you're safe from DOSes from <img> (which have been on the 
Web for 17 years or so now), you're safe from this one.


> - Can be used for port mapping.

No more so than <img>, or XHR, or <script src="">, or pretty much any 
other mechanism in HTML today.


> -- But as you've written, there are other ways, so then it is acceptable?

I'm certainly open to suggestions for avoiding this problem, but short of 
introducing random delays, I don't see how to fix it. Unless we force a 
port, which I don't see how we can do, a policy file would have the same 
problem (just use the policy file to do the port scanning).


> - Part of the security of the protocol relies on the fact that the 
> clients can't use "raw" TCP sockets. This is not always true if the 
> client has the flash, java or the Silverlight plugins. What about future 
> plugins or APIs?

What about them?


> -- During a transition phase to html5, I would think that people would 
> simulate the Web Socket API via scriptable flash clients since most 
> users already have it installed, so this would probably become rather 
> common. Someone might also do the same via Silverlight.

Actually so far most people have emulated it using XHR.


> - Makes it simpler to implement authentication and SSO against Web 
> Socket services.

Not sure what you mean here.


Fundamentally, raw sockets plus a policy file is a completely different 
approach than Web Sockets. I would recommend developing a second proposal 
separate from the Web Sockets spec, and approaching browser vendors to see 
if they prefer it.

Personally I think there are huge problems with offering raw sockets plus 
a policy file that Web Sockets carefully avoids:

 - raw sockets are stream-based, not packet based, which is quite a lot 
   harder to program against (Web Sockets is aimed at both professionals
   and amateurs, and thus avoids exposing the underlying stream to the 
   authors, since they are likely to trip up authors).

 - raw sockets mean a binary interface, which is not possible natiely in 
   JS currently. It also means exposing authors to the world of character 
   encodings, a hell of momentous proportions (Web Sockets avoids this by 
   being UTF-8-only).

 - policy files require two network connections to set up a socket (Web 
   Sockets is specifically designed to avoid ever using more than one).

 - policy files are hard to do right, e.g. either you force a specific 
   port and policy mechanism, or you open yourself to shared-hosting 
   attacks, upload attacks where the attack causes a policy to be uploaded 
   to a victim site, and other problems which have plagued Flash for 
   years. (Web Sockets sidesteps all of this by not using policy files.)

 - raw sockets means we can't address multiple services per port. (Web 
   Sockets supports this natively.)

 - raw sockets means authors have to do host-rebinding protection. (Web 
   Sockets protects against this natively.)

 - mistakes in a policy file can lead to serious but undetected attacks, 
   e.g. spammers using local SMTP servers. (Web Sockets prevents use of 
   SMTP servers entirely.)

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

Received on Monday, 1 February 2010 09:47:55 UTC