Re: [hybi] handshake security (was: Frame size)

[Ian Hickson <[e-mail]>]

On Mon, 19 Apr 2010, Thomson, Martin wrote:
> >
> > The idea is not to make the client able to do anything, the idea is to 
> > make the server more likely to fail to get to the point where it is 
> > accepting frames without having checked that it's a Web Socket client.
> 
> That's the tension.  The lazy server implementer does the minimum that 
> they believe they can get away with.  If they have to interoperate with 
> browsers, they will do the minimum to interoperate with browsers.
> 
> That leaves a lot of room for error - and you know what, that's probably 
> OK.  The only one who suffers is the server implementer.  They are the 
> ones being duped.

Also the user.

I think that both the implementor getting duped and the user getting duped 
are problems that we should do our best to help with. I do not want to be 
responsible for developing a protocol where half the deployments are 
vulnerable to attack, even if those bugs are technically flaws in the 
implementations and not in the protocol.


> The WS-aware browser works it out pretty quickly; the WS-ignorant 
> browser probably chokes on the Upgrade header in the response, and if 
> not then, they will eventually fail.

Not sure what this means. What's the browser got to do with it? In this 
attack scenario, the browser thinks it's talking HTTP (indeed it could 
be a legacy browser and thus not know about Web Sockets at all), and the 
response is hidden from the user, so regardless of what the browser thinks 
might be going on, the user is never informed.


> > > If the server only looks for certain markers, then I imagine that an 
> > > SMTP message could trigger launch in the same fashion.  It doesn't 
> > > stop the attack.
> > 
> > I don't see how you could cause any privileged machine in this 
> > scenario to connect to the Web Socket server using SMTP. Could you 
> > elaborate on that?
> 
> The point being that if a server only searches for certain byte 
> sequences, those byte sequences can be embedded in any protocol you 
> like.  Nothing you do as a specification writer helps the server that is 
> able to mistake another TCP-borne protocol for WS.
> 
> The mechanism doesn't stop an attack.  It only provides a higher bar to 
> entry for server developers.

Could you describe an attack that uses SMTP? I honest can't see a concrete 
way to abuse this mechanism with SMTP.

If there's a way to cause a machine with elevated privileges to send a 
payload that is sufficiently like Web Socket to a Web Socket port on an 
arbitrary machine, then that's a huge problem. Is there such a mechanism, 
other than XHR or form submission triggered by a hortile page viewed in an 
Web browser?


> Sure, the handshake provides incentive for server developers to do the 
> right thing... inasmuch as it is probably easier then to do the right 
> thing than the wrong thing once the handshake is implemented.

Right, that's the idea.


> On the other hand, it doesn't provide any real assurances to either 
> party.

If there's a way to make it even better, I'm all ears.


> We still have to take it on faith that the server implementation isn't 
> brain-dead.  But that's possible without the mechanism.

Unless we make things very easy to get right, authors will get it wrong, 
often in spectacularly bad ways. We've seen this again and again, with XSS 
all over the Web, with XSRF all over the Web, with information leakage 
through <script src=""> and JSON, etc. We have no reason to believe that 
Web Socket implementors are going to be any more competent (unless we make 
the protocol so complicated they can't begin to implement it, like HTTP, 
but then we run into the problems I described recently [1]).

[1] http://www.ietf.org/mail-archive/web/hybi/current/msg01691.html


> > > It's quite possible that any viable solution to that problem would 
> > > be more trouble than it's worth.  (you know, there might be a 
> > > business in that...)
> > 
> > Not sure what you mean.
> 
> Sorry, just me being obtuse:
> 
>   More trouble than it's worth == more round trips and latency, more complicated mechanisms.

It was the "there might be a business in that" part that confused me more.

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