Re: [hybi] A WebSocket handshake

[Adam Barth <[e-mail]>]

On Wed, Oct 6, 2010 at 11:42 PM, Greg Wilkins <[e-mail]> wrote:
> On 7 October 2010 16:23, Adam Barth <[e-mail]> wrote:
>>>> === Handshake Request ===
>> That's factually inaccurate.  The URL and subprotocol information is
>> included in the initial encrypted.
>
> I'm sorry - I was confused by your statement that "The attacker cannot
> influence
> any of the bytes included in the message".   Your proposal read like
> this information was
> sent in a subsequent request.

Perhaps a better wording would have been "The attacker cannot choose
any of the bytes sent on the wire."  I've updated the document.

> So an attacker can influence the bytes in the handshake.

Yes, but the attacker cannot choose any of the bytes sent on the wire,
which is one of the essential security properties of the handshake.
That makes it quite difficult for the attacker to confuse
non-WebSocket servers (which won't decrypt the additional information
because they lack the UUID).

>> No.
>> [...]
>> Fortunately, this handshake does not punish correctly implemented
>> intermediaries.
>
> Care to explain?
>
> You say that an intermediary that understands CONNECT will route to a
> non-existent domain.
> How will such an intermediary be able to work with websocket?

Such an intermediary is not correctly implemented.

>> The attacker in our threat model is not allowed to provide a proxy
>> autoconfig file.
>
> again - probably true... but I'd like to see the detailed anaysis as
> to why that is so.

This is standard stuff in web security.  An attacker who controls your
proxy autoconfig is equivalent to an active network attacker.

> There are basically two elements to it, that I actually should be
> considered separately and as incremental proposal to the current
> draft.
>
> 1) Encrypt the user/attacker supplied data.    There may be some merit
> in this, but it can be equally applied to the upgrade approach as it
> can to a CONNECT approach.   But you analysis of the threat is based
> on a strawman and I do not believe that you have substantiated any
> significant vulnerability where a URL or field value of a HTTP request
> may be interpreted as content in another protocol - that is not
> already vulnerable to HTTP clients.  Without an real threat, I do not
> believe that encryption is worth while.
>
> 2) Use of CONNECT rather than upgrade.  Again, there is some merit in
> considering this, but I believe it has been discussed before and
> eventually rejected.  There is the issue that an intermediary that
> correctly implements CONNECT will not pass such a hand shake.  If that
> concern can be addressed, and if we can do some real world testing of
> how CONNECT performs, then maybe it is a candidate.

Yes.  Both those aspects are important to the security of the
handshake.  I don't believe the handshake is secure without them.

Adam