Re: [hybi] A WebSocket handshake

[Adam Barth <[e-mail]>]

On Wed, Oct 6, 2010 at 7:33 PM, Greg Wilkins <[e-mail]> wrote:
> On 6 October 2010 09:15, Adam Barth <[e-mail]> wrote:
>> == Strawmen ==
>> If  the attacker can host an htaccess file at any location a target HTTP server,
>
> This is indeed a strawman.

Hence the title.  :)

>> Consider, for example, a virtual hosting environment in which the attacker can place PHP scripts on the server.
>
> Then again, the attacker already owns the server. They can write a
> script to echo back any cookie or content from any script or XHR, so
> the clients cookies are already been exposed.  This has nothing to do
> with websockets.

That's not correct.  As cited in the paper, there are many folks who
will virtually host my PHP scripts with other customers.  The security
architecture of the web makes that safe.  Resources are allocated by
origin.  The virtual hosts have different origins.

>> === Handshake Request ===
>> 1) The attacker cannot influence any of the bytes included in the
>> message.
>
> If the attacker cannot influence any of the bytes in the handshake,
> then an extra round trip will be needed to communicate the WebSocket
> URL and subprotocol. Ideally these need to be known before a server
> proceeds with accepting a websocket connection.

That's factually inaccurate.  The URL and subprotocol information is
included in the initial encrypted.

> Thus I think it is unrealistic to propose a content free handshake.

Fortunately, that's not what we proposed.

> Unfortunately, once you allow content (which I think we must), then a
> CONNECT handshake is just as vulnerable to cross protocol attacks to
> DNS servers as HTTP is.

That is factually inaccurate.  Please see the protocol described above
as a counter-example.

> If those servers are going to interpret the
> method as a frame header and then scan forward to the arbitrary
> content provided by the attacker, then they will be equally vulnerable
> to POST, GET or CONNECT (with perhaps some variance due to the happen
> stance of the actual ascii values of those names).

That is factually inaccurate.  Please see the protocol described above
as a counter-example.

> But luckily, you
> have already demonstrated that DNS like servers are not vulnerable to
> HTTP with GET and POST, so they are thus not vulnerable to CONNECT.
> But this proposal still does not represent any real change of
> substance.

That is factually inaccurate.  I made no such demonstration.

>> 2) Any intermediaries that understand this message according to its
>> HTTP semantics with route the request to a non-existent domain and
>> fail the request.  In particular, they will not route the
>> Sec-WebSocket-Key to the attacker, making it difficult for the
>> attacker to perform actions based on the key.
>
> So that would mean that an intermediary that correctly implements both
> CONNECT and
> upgrade headers would not be able to work with websockets using this
> handshake, while it could with the currently proposed handshake.

No.

> I don't think we should have a handshake that punishes correctly
> implemented intermediaries.

Fortunately, this handshake does not punish correctly implemented
intermediaries.

>> 4) This message cannot be generated by a web attacker in today’s browsers.
>
> I expect this is true, although I would like to review the various
> auto proxy configuration mechanisms that are available, as they may
> allow a compromised CONNECT request.

The attacker in our threat model is not allowed to provide a proxy
autoconfig file.

>> == Conclusion ==
>>
>> We believe this handshake is superior to the current handshake because
>> this handshake has a stronger argument for security.  Because the
>> attacker cannot control any of the bytes sent by the browser, the
>> attacker will have difficulty mounting a cross-protocol attack using
>> this handshake.
>
> The strawman analysis of the threat to the upgrade handshake is indeed
> a strawman and thus can't be used to justify any claims of
> superiority.

I disagree.

> Also the main security aspect of this handshake is that it does not
> allow attacker supplied content.  This provides a secure but
> non-functional handshake.

That is factually inaccurate because you do not understand the
handshake as described.  Please read the paragraph about the encrypted
additional information included in the initial message.

On Wed, Oct 6, 2010 at 7:42 PM, Greg Wilkins <[e-mail]> wrote:
> On 7 October 2010 01:21, Adam Barth <[e-mail]> wrote:
>> We'll put the WebSocket URL in the additional information that comes
>> with the initial message.  We can either break that up into a request
>> line and a Host header, or we can just include the whole URL as such.
>
> I think you make the server more vulnerable to DOS attacks by delaying
> consideration of the URL and subprotocol.

That is factually inaccurate.  I did not delay the consideration of
the URL or the subprotocol.

> Frequently servers will run many applications on many virtual hosts,
> real hosts and context paths.  Only a subset of these may support
> websockets.  This proposal would mean that the server would need to
> accept the connection and thus cause the client onOpen even to first,
> before it had validated the connection was to an application that can
> handle websocket.  While I don't see any new vulnerability flowing
> directly from this, I believe that it is not a desirable state of
> affairs from either a security or resource allocation point of view.

That is factually inaccurate, for the reasons described above.

>> The point of putting in the additional information is so that it can
>> be encrypted, preventing the attacker from choosing any of the bytes
>> on the wire.
>
> If we really are going to have a content free handshake that exchanges
> keys so that the rest of the connection can be encrypted - then we
> should just use TLS.

I agree that we should use TLS, but the premise of your statement is
misinformed.  The handshake is not content free.

> I see little value and significant risks in inventing some TLS-lite handshake.
>
> I think that we should improve the upgrade proposal to the best we
> can, and consider a concrete TLS proposal, and then we can consider if
> we support one or  the other or both.

The handshake in this document is an improvement on the upgrade
handshake.  Given that you didn't understand how this handshake works,
I'd encourage you to reconsider your position.

Adam