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

[Adam Barth <[e-mail]>]

Please read my later message.  That should give you a more concrete
understanding of the issue.

(minor points inline)

On Fri, Oct 1, 2010 at 5:45 PM, Scott Ferguson <[e-mail]> wrote:
> Adam Barth wrote:
>>
>> On Thu, Sep 30, 2010 at 6:50 PM, Scott Ferguson <[e-mail]> wrote:
>>
>>>
>>> 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
>>>
>>
>> You're making a bunch of assumptions about how non-websocket servers
>> behave.  In particular, consider a protocol like DNS.  It's entirely
>> possible that a DNS-like protocol could relay the c-nonce to the
>> attacker and give the attacker an opportunity to response with the
>> appropriate hash, which the server would then relay to the client.
>> Attacks of this general class (even against DNS) are known for HTTP.
>>
>
> No, Adam, you can't just handwave that scenario. Let's take your attack in
> detail.
>
>  1) Hijacker has taken control of a browser and initiates a websocket
> connection.
>  2) That websocket connection is to a DNS server.
>  3) The DNS server relays the c-nonce to the hijacked browser (???)
>
>      browser -> DNS -> browser
>
>  4) The hijacked browser can now compute H(c-nonce, "WebSocket")
>  5) The browser somehow sends the H(c-nonce, "WebSocket") to the DNS proxy
> which now that it has the hash redirects to the actual target, which echos
> the hash through the theoretical proxy chain. Or it acts as a web-socket
> relay itself
>
>      browser -> DNS -> browser -> target
>
> None of which makes any sense.
>
> I am making some assumptions:
>
>  1) there are no websocket open relays. If there are, the issue isn't a
> cross-protocol attack, but an open relay attack. Your description proposes
> the browser itself as a websocket open relay ("could relay the c-nonce to
> the attacker").
>
>  2) there are no open relays that compute H(xxxx, "WebSocket") or open
> relays that calculate arbitrary hashes H(xxxx).  Your proposed DNS attack
> does neither, nor does it propose a relay that does calculate either.
> Instead, you handwave to the hijacked browser itself as an open websocket
> relay.
>
>> The security of this protocol relies on more assumptions than you've
>> listed in your message.  Reasoning about security here is very subtle,
>> especially when reasoning about the behavior of non-WebSocket servers.
>>  We need to be prepared for them to do a wide variety of things.
>>
>
> This statement is not particularly useful.
>
> If you assume the existence of open relays which implement arbitrary
> protocols and compute arbitrary functions, that's equivalent to assuming the
> relay is a valid websocket proxy, which is no longer a cross-protocol
> attack.
>
> Does your "wide variety of things" include calculation of arbitrary hashes?
>
>> As a side note, using an exotic HTTP method is not a good idea.  The
>> first few bytes of the clients initial message are absolutely
>> critical.  Picking an exotic HTTP method is just rolling the dice
>> w.r.t. what protocols an attacker can exploit.  For example, some
>> attacks from HTTP to DNS rely critically on the fact that the first
>> byte of an HTTP POST message is an uppercase P.  The kinds of things
>> you can do with an uppercase W as the first byte are largely
>> unstudied.
>>
>
> You misunderstand entirely.
>
> It's not an exotic HTTP method; it's identifying the protocol by the initial
> sequence of bytes.

Exotic => can't be sent by web sites to arbitrary hosts today in browsers.

> If every client for every protocol sent a non-hijackable unique protocol
> identifier as its initial sequence, and every server for every protocol
> verified the protocol identifier before accepting any further bytes, then
> cross protocol attacks would be impossible.

Sure, but there are plenty of protocols that don't do that.

> We can't fix the older protocols that don't identify themselves immediately
> and don't validate, but we can ensure that new protocols do.

Unfortunately, we don't have the luxury of ignoring attacks against
these "older" protocols.

Adam