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

[Maciej Stachowiak <[e-mail]>]

On Sep 29, 2010, at 3:28 AM, Greg Wilkins wrote:

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

The idea is that you make an HTTP request with a header that looks close enough to the WS handshake to fool the server, followed by what appear to be WS messages in the body.

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

Because you can't inject whitespace into the resource name in the request line.

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

Sticking something that looks like a Sec- header into the request line is possible (that is under the attacker's control with both WebSocket and HTTP APIs) but you can't include whitespace - it will get stripped or percent-escaped.

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

Your proposal implied only a single nonce value, but I agree that aspect is not an essential part of your proposal.

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

For the record, I don't think the unframed random bytes in the request add any security value.

As I understand it, they are intended to trigger fast-fail in unaware intermediaries without extra round trips. I do not personally have any data on whether they work for this purpose. We do seem to have some data that it causes unnecessary failures to connect. Any way to detect intermediaries that can't support WebSocket should ideally be tested in the field in some way (much as the older -75 handshake was). This applies both to new proposals and the -76 handshake, as far as I am concerned.

Personally, I would prefer if failure-detection mechanisms were kept separate from security mechanisms if possible.

Regards,
Maciej