Re: [hybi] Shipping WebSockets

[Willy Tarreau <[e-mail]>]

On Thu, Dec 16, 2010 at 10:50:12AM +0100, Bjoern Hoehrmann wrote:
> * Gabriel Montenegro wrote:
> >FYI, we have submitted a draft that's essentially the handshake that Greg proposed a while back.
> >We'd like to use it as a basis for further iteration.
> >
> >http://tools.ietf.org/html/draft-montenegro-hybi-upgrade-hello-handshake
> 
> This seems broken to me if you make three assumptions: implementations
> don't stop normal HTTP processing if they see a 101 (that's the working
> assumption that makes us discuss handshakes at all); it's fairly common
> for servers to send response bodies when they are not supposed to, e.g.
> in response to HEAD requests, so implementations treat unexpected bodies
> as part of the response to the previous request; implementations do only
> very limited input validation, for instance, when looking for a method,
> they just skip to the next white space octet.
> 
> With these assumptions it would seem the server->client hello would be
> treated as response body and the client->server hello as request method.
> Since what follows the unknown request method is essentially controlled
> by the attacker, that amounts to a normal HTTP request. I am sure each
> of these flaws can be found in deployed software; their combination plus
> additional behavior that makes them exploitable (you also need, say,
> persistent connections) is probably rare, but unless I am misreading the
> document, this seems insufficient if you care a lot about this problem.

If the server's data is treated as a response body, this is fine, because
it will be treated as the handshake request's response, it cannot be sent
as a response to a second request.

The processings we can see on a 101 response are :
  - intermediary considers 1xx as error and stops => OK

  - intermediary does not know about 1xx and forwards it as it would for
    a 2xx or 3xx => since we have no content-length, the end of the response
    is indicated by closing the connection after the "body"

  - intermediary only knows that 1xx has no body but forwards it as a
    single response and believes that what follows is the response to
    a second request => the client hello must be accepted as a valid
    HTTP request for the server hello to be parsed, then accepted in
    turn as a valid HTTP response. None of them look like HTTP, and
    that's the point.

  - intermediary knows that 1xx is an intermediate message without body
    and waits for a second one right after it => it parses the server
    hello expecting to find an HTTP response here, which it does not
    look like at all.

  - intermediary knows about 101 and establishes the bidirectional tunnel
    between the two sides and we're OK.

I don't see a way to abuse any non-compliant intermediary here.

Regards,
Willy