Re: [hybi] Handshake was: The WebSocket protocol issues.

[Greg Wilkins <[e-mail]>]

On 29 September 2010 18:56, Maciej Stachowiak <[e-mail]> wrote:
> The raw HTTP request can include a body, which is sent immediately, rather
> than waiting for the remainder of the handshake. The body can include
> content framed as WS protocol messages. A WebSocket client will wait until
> the handshake is complete. So yes, the possibility of attempting an HTTP
> connection to a WebSocket server does create additional attack surface.

But how is the HTTP header going to be skipped by the WS server in
order for it to find these encapsulated WS messages?

Both a HTTP server and a WS server will consume all of any HTTP
request sent to it, so content will not be mistaken as new messages.

It is not sufficient just to send WS frames over the wire.  You have
to explain how they are
going to be sent so that a server will actually read them and
interpret them WS messages.



> I suspect -76 is not strong enough, but it is slightly stronger in some
> specific ways. First, by spreading the data across multiple header fields
> and incorporating whitespace, it makes it slightly trickier to do injection
> attacks.

Why is hex encoding simpler to inject than the space/char injected
decimal encoding?
The white space fields originate from the client and do not need to be
injected into
the server response.

Can you explain any scenario where a HTTP client could somehow send Sec- fields
without spaces, but could not send ones with spaces?

Also I've not proposed having only a single key field. We can still
have two fields,
so thus require data from multiple header fields.


I think the bulk of your concerns are about HTTP handshakes in general and
not specifically about my proposals to fix the handshake issues that
we have now.
Let's not forget that the current handshake with unframed random bytes
is causing
real problems with intermediaries now - so it needs to be fixed.


regards