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

On Mon, 1 Feb 2010, Sebastian Andersson wrote:
> On Mon, Feb 1, 2010 at 10:47, Ian Hickson <ian@hixie.ch> wrote:
> > 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?
> 
> I think it is pretty obvious. Do it like Silverlight! The policy file
> is downloaded from port 943. If it is not available there, you have no
> right to connect to this IP number.

So anyone who's behind a firewall that blocks all but ports 80 and 443 is 
blocked from using Web Sockets? That's a pretty serious problem.


> How do you protect your Web Socket service from another user on your 
> shared host? They can publish flash clients and java applets that 
> connects to your server and present any origin they want.

Like I said, Flash has all kinds of security problems.

(The risk in this case is minimal, though, since it wouldn't send ambient 
authority headers -- like Cookies -- with the request, which are the main 
problem in a shared hosting environment.)


> >> -- 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.
> 
> From section 5.1 in the protocol specification:
> "Servers that are not intended to process input from any Web page but
>    only for certain sites should verify the "Origin" header is an origin
>    they expect, and should only respond with the corresponding
>    "WebSocket-Origin" if it is an accepted origin"
> 
> I think that covers a large proportion of the servers and I think that 
> most projects would want to implement support for it just to allow 
> different server deployment scenarios.

I would imagine most would only accept connections from _one_ site, and 
they can just send back the appropriate WebSocket-Origin without checking 
what the client has sent.


> > 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.
> 
> Ok. Perhaps I'm pessimistic here, but I fear that one important browser 
> vendor would prefer that raw sockets were not added so their own 
> competing technology remains a better choice and if the Web Socket 
> protocol is part of html 5, it is easier for them to just say no. I hope 
> I'm wrong though.

Well if that's the case, we wouldn't be able to change Web Socket either.


For the rest of your points, we're basically just disagreeing with each 
other's priorities, not with the facts. So I don't think we can make much 
progress. Your ideas are not wrong, they're just solving a different set 
of problems, or a set of problems with different priorities, than what Web 
Socket is setting out to solve. I really _would_ recommend approaching 
browser vendors and seeing if they would prefer a different approach, or 
another approach in addition to this one, and then if they do, editing a 
spec for that new approach.

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

Received on Tuesday, 2 February 2010 02:52:22 UTC