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

[Scott Ferguson <[e-mail]>]

Adam Barth wrote:
> On Thu, Sep 30, 2010 at 9:42 AM, Scott Ferguson <[e-mail]> wrote:
>   
>> Maciej Stachowiak wrote:
>>     
>>> On Sep 29, 2010, at 3:28 AM, Greg Wilkins wrote:
>>>       
>>>> On 29 September 2010 18:56, Maciej Stachowiak <[e-mail]> wrote:
>>>>         
>>>>> 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.
>>>       
>> Maciej, you're missing the entire point of the hash.  The main purpose of a
>> hash/digest is to detect modification or replacement of a message as in an
>> injection attack. That's what a digest does.
>>     
>
> If that's the purpose of the hash, which elements of the protocol
> defend against cross-protocol attacks?
>   

Ok. I think it's a good idea to step back a bit so we don't get lost in 
the weeds, because the injection discussion is a bit of a distraction.

The two main defenses against the cross protocol attack are:

  1) the client verifies the server as the same protocol before sending 
potentially damaging data ("server validation").

  2) the server verifies the client as the same protocol before 
interpreting potentially damaging data ("client validation").

For 1), server validation, the hash proposal accomplishes server 
validation based on the following:

  a) non-websocket servers will not be in possession of the "WebSocket" 
identifier
  b) c-nonce is not available to or predictable by the hijacker
  c) H(c-nonce, "WebSocket") cannot be produced by the hijacker, i.e. 
the hijacker can't get around its ignorance of (b) by producing a hash 
collision.

On the injection side-issue, as long as the hijacker cannot force a 
collision of the hash, any injection of c-nonce will be detected and 
rejected, because producing a bogus c-nonce will result in a bogus hash 
and therefore a rejection by the client before it sends damaging data.

If we're worried about injection into other parts of the request, like 
the URL, we could include them into the hash, so the client could verify 
that the server received the URL it thinks it sent. (As long as that 
change doesn't enable collisions of the resulting hash function.)

As a side effect, the hash function protects servers that don't 
calculate the hash at all, but that's not a sufficient defense, because 
a future protocol could copy the WebSockets handshake hash functions. 
But that calculation protection and the protection against injection are 
not the critical pieces. It's (a)-(c) that are providing the defense.

For 2), client validation, there are two independent defenses

2.1) "WEBSOCKET" method. If a hijacker cannot produce the "WEBSOCKET_" 
bytes because the browsers restrict HTTP methods, the server can verify 
the client as websocket with the first bytes, with the side effect of 
offering a limited defense for some non-websocket servers against URL 
and header cross-protocol attacks.

2.2) PING/PONG hash.

  a) s-nonce is not available to or predictable by the hijacker
  b) A non-websocket client is not in possession of the "WebSocket" 
identifier
  c) H(s-nonce, "WebSocket") cannot be produced by the hijacker and will 
not be produced by the hijacked non-websocket protocol.

In this case, for (b,c) I'm really thinking of some future non-HTTP 
protocol in the browser. It would be possible for a future protocol to 
follow the lead of WebSocket and use the same PONG hash calculation. But 
that future client will not be in possession of the "WebSocket" bytes. 
It's a bit of overkill for HTTP clients, but I think it would useful to 
handle future protocols.

To repeat the key pieces:

  a) c-nonce must not be available to or predictable by the hijacker
  b) "WebSocket" is not possessed by a non-websocket server
  c) s-nonce must not be available to or predictable by the hijacker
  d) "WebSocket" is not possessed by a non-websocket client
  e) the hashes must not have predictable collisions

  f) this does not protect non-validating servers against URL or HTTP 
header cross-protocol  attacks; its defense is limited to the frame stream.

-- Scott
> Adam
>
>
>
>