Re: [hybi] Web sockets and existing HTTP stacks

[Maciej Stachowiak <[e-mail]>]

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

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

Regards,
Maciej