Re: [hybi] Web sockets and existing HTTP stacks

[Roberto Peon <[e-mail]>]

On Wed, Feb 3, 2010 at 2:02 AM, Maciej Stachowiak <[e-mail]> wrote:

>
> On Feb 3, 2010, at 1:07 AM, Roberto Peon wrote:
>
> >
> > How exactly does the random bit of text in the first line help?
>
> In the case of a cross-protocol attack against HTTP, it's likely harder to
> inject text into the status line than it is to inject a response header, so
> that's the reason why it is in the first line. In the case of a
> cross-protocol attack against other protocols, in general it's harder to
> mess with the very beginning of the server response than the end (though not
> always).
>
> The text is not random, it is a hash of some information from the request.
> The reason for the particular nature of the bit of text is to further
> increase the challenge of cross-protocol attacks by requiring the handshake
> response to contain something that (a) cannot be predicted before client JS
> tries to initiate the connection; and (b) is not a verbatim echo of anything
> in the handshake request. So even if you can find a server that will echo
> back exact text of your choice, or pieces of the request of your choice, you
> cannot make it return what appears to be a valid handshake response.
>

You can still do this as an HTTP header.


>
> > You still have to frame the HTTP response, which means that any errors in
> that framing are going to be causing problems.
>
> I don't understand what kinds of problems you have in mind, could you
> clarify?
>

HTTP header injection problems: If it is possible, you can get interesting
things to happen. This true of anything which is attempting to frame HTTP,
and thus isn't limited to WebSockets, however, when it happens on a server
there is no way to recover safely. The real problem with these is that the
server has no idea that it happened without scanning its own output to see
that it is framed the way it expects (and I don't know of any server which
does this).


>
> > In other words, the response will always be as insecure as HTTP. No way
> around that while still using HTTP. And, as we've already covered, not using
> HTTP isn't a terribly good option while on port 80 until the upgrade has
> finished.
>
> Again, I don't know what you mean by "as insecure as HTTP". Specifically
> what we're worried about here are cross-protocol attacks (both using
> WebSocket and against a WebSocket service). The fact that the handshake
> format is an HTTP request does increase the risk in both directions, but we
> can do things to mitigate it. If you think my proposed defense is
> ineffective, could you explain how?
>

MitM still works just fine even with the hash value.
What is the attack vector that you see mitigated? I may just not be seeing
it.

-=R


> Regards,
> Maciej
>
>