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

[Maciej Stachowiak <[e-mail]>]

On Sep 29, 2010, at 3:08 PM, Greg Wilkins wrote:

> On 30 September 2010 02:47, Maciej Stachowiak <[e-mail]> wrote:
>>> 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.
> 
> It is very hard to imagine a server that is so broken that it will
> allow injection of fully formed HTTP requests, responses into a URL,
> complete with CRLF etc. but that will not allow spaces to be injected.

The injection we are talking about is client side, not server side. All browser-hosted HTTP and WebSocket APIs let you provide a URL, but will not send a request line that contains whitespace.

> 
> Also, the attacks described do not need to inject the space encoded
> fields.  They are part of the request and the attacker is happy for
> the server to just ignore them.  The attacker is trying to inject a
> valid 101 response.

We're clearly not using "inject" in the same way. When I say "injected", I mean "caused by the attacker to be inserted into a browser-generated request that they do not fully control"

> 
> Unless you are concerned that somehow the WS server will see the URL
> in the upgrade request as a second upgrade request??

I don't see how this relates to my scenario. It doesn't involve a second upgrade request.

> but simple WS servers are not going to process multiple HTTP requests
> and complex ones are going to have real HTTP parsers that should not
> be vulnerable to such an attack - if they were, then they are so
> broken that spaces are not going to make a difference, because you
> must also be able to inject CRLF.

You only need to be able to inject CRLF if something about the server-side check is required to look at multiple lines. Imagine poorly coded regexp-matching parsers that look at one line at a time.


> 
> 
> 
> 
>>> 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.
> 
> Injecting such things into request lines is normally part of an attack
> to cause the server to echo that content back as part of a response.
> There is no benefit of putting Sec- headers into the response.

Perhaps, but I don't believe that is the scenario the whitespace encoding was meant to address. I don't think the whitespace encoding of the nonce is particularly powerful, but it does have an effect.

> 
> Having Sec-header content in the request line is not going to make the
> server see that as another HTTP request or as part of the current HTTP
> request - unless it is so broken that CRLF can be inject, in which
> case I don't think spaces are much protection.

The client can't generally be tricked into putting CRLF into the request line (though occasionally a bug like that crops up and creates security vulnerabilities).

> 
>> For the record, I don't think the unframed random bytes in the request add any security value.
> 
> Then why are you fighting so hard against my reasonable proposals?

I'm not "fighting against" your proposal, I am explaining how your proposed handshake creates security risk. I also think the current handshake creates security risk (maybe a tiny iota less).

> 
> Couldn't you just have said +1 to framing those bytes, but I'm a
> little worried about taking the spaces out???
> Did you really need to start this whole thread questioning my
> capabilities to understand a cross protocol attack?

I jumped in this thread solely to inject information about the risks of cross-protocol attacks, since it seemed like no one was thinking about the HTTP vs. WebSocket attack vector. At that point, people reacted skeptically and/or indignantly, so I tried to explain further. I am still not sure I have fully explained the risks adequately.

You made security claims about your handshake proposal - that is the sort of thing that invites scrutiny and security review. My comments so far are not even a particularly deep review.

> 
>> Personally, I would prefer if failure-detection mechanisms were kept separate from security mechanisms if possible.
> 
> I have long argued for that.   In fact I believe that it would be
> sufficient to put the hash into a response header.
> However, some appear to have concerns with that - so I was proposing
> minimal changes to try to fix the broken handshake.
> If you think we should go further, then that is no reason to argue
> against the modest proposals that I have made:
> 
>  + frame the random bytes as websocket frames
>  + don't send ws frames until after 101.
>  + use a simple hex encoding for the nonce

My alternate proposal is that we drop HTTP-based handshakes entirely in favor of TLS+NPN. But I have also suggested several specific ways to make your proposed scheme more robust (server-side nonce, one-time-pad of the data frames, etc).

Regards,
Maciej