Re: [hybi] A WebSocket handshake

[Greg Wilkins <[e-mail]>]

On 7 October 2010 16:23, Adam Barth <[e-mail]> wrote:
> 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.  :)

You do know what a strawman is right?

   http://en.wikipedia.org/wiki/Straw_man

Strawmen have no place in a reasoned discussion.



> 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.

Exactly - the security architecture of the web makes that safe.
No cookies or credentials for goodguy.somehost.com/secret/ are going
to be sent to
evilgenius.somehost.com/attack.

Also hosting PHP is not sufficient to be able to accept a websocket handshake.
It must be able to send a 101 response and then generate a valid ping
message (or the
correct random bytes in the -02 draft).

You are only revealing vulnerabilities in a strawman server that
you've hypothesised to be vulnerable.



>>> === 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.

So an attacker can influence the bytes in the handshake.

> 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?



> 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.



> Given that you didn't understand how this handshake works,
> I'd encourage you to reconsider your position.

I did misunderstand your statement that the attacker cannot influence
any of the bytes included in the handshake, but have now reread the
proposal and think that I've got the nuts of it.

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.


regards