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

["Thomson, Martin" <[e-mail]>]

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

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.

> > 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.  There is already a means by which the server tells that the request is not a WebSocket request: checking for the presence of the correct Upgrade header.

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.  On the other hand, it doesn't provide any real assurances to either party.

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

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

--Martin