Re: [hybi] New port and Tunneling?

"Shelby Moore" <shelby@coolpage.com> Tue, 17 August 2010 11:23 UTC

Return-Path: <shelby@coolpage.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 345EF3A682A for <hybi@core3.amsl.com>; Tue, 17 Aug 2010 04:23:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.232
X-Spam-Level:
X-Spam-Status: No, score=-0.232 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_50=0.001, J_CHICKENPOX_46=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgiVqLnejZiu for <hybi@core3.amsl.com>; Tue, 17 Aug 2010 04:23:17 -0700 (PDT)
Received: from www5.webmail.pair.com (www5.webmail.pair.com [66.39.3.83]) by core3.amsl.com (Postfix) with SMTP id DC32F3A6768 for <hybi@ietf.org>; Tue, 17 Aug 2010 04:23:16 -0700 (PDT)
Received: (qmail 32928 invoked by uid 65534); 17 Aug 2010 11:23:50 -0000
Received: from 121.97.54.174 ([121.97.54.174]) (SquirrelMail authenticated user shelby@coolpage.com) by sm.webmail.pair.com with HTTP; Tue, 17 Aug 2010 07:23:50 -0400
Message-ID: <9e3c9de9b6d6278aa26921f4b22963ad.squirrel@sm.webmail.pair.com>
Date: Tue, 17 Aug 2010 07:23:50 -0400
From: Shelby Moore <shelby@coolpage.com>
To: Vladimir Katardjiev <vladimir@d2dx.com>
User-Agent: SquirrelMail/1.4.20
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] New port and Tunneling?
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: shelby@coolpage.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Aug 2010 11:23:22 -0000

I have edited my prior reply[1], not to add or change any point, but to
clarify some ambiguity and compact my verbage...(refer back to the prior
reply for some nuances that have been compacted out of this current reply)

[1] http://www.ietf.org/mail-archive/web/hybi/current/msg03303.html

Apology for the reading load of my messages, I anticipate it will soon
taper down, as my main points are clearly communicated to the list.  Then
I can comment more infrequently if I see something sufficiently important
that others did not point out after some time.

below...


> On 16 aug 2010, at 20.18, Shelby Moore wrote:
>
>> Some Benefits of port+tunnel (other benefits have already been
>> mentioned)
>>
>> =====
>> P2P:
>>
>> Perhaps a big bonus of port+tunnel, is we could then allow P2P
>> connections for WebSockets. That would be a huge, super huge feature.
Success rates are apparently around 69%. Fall back to Comet/BOSH to an
HTTP server for the remaining 31% (similar rates of fall back be
necessary
>> for other proposed transports too).
>>
>> The Same Origin Policy does (and SHOULD) not apply to cross-site
communication when the HTTP cookies and/or any form of HTTP session
persistance are not involved[1].
>>
>> [1]
>> http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_XMLHttpRequest
>>
>> That may be a controversial statement, but I am able to explain in
exhaustive detail if any one doubts it.  Summary is that since the user
trusts the page he/she is viewing and that is communicating, the user
trusts that viewed page to not load resources which would be malicious,
and thus the only vulnerability that is not the responsibility of the
other site involved in communication, is the one where the other site
can
>> be tricked into doing something on the user's credentials for that
other site.
>>
>
> I'm not sure what the point is here. Yes, you are correct in that the
SOP no longer applies to WebSockets, but this has been true from the
get-go.
> However, the _origin policy_ still applies very much. Mostly because
even if the _user_ might think one thing, neither browsers nor
enterprises expect most users to know any better.
> Since browsers are, more and more,
> becoming execution environments that automatically run the executable
code they download, this is a very important point of restriction. Web
pages should not be able to arbitrarily initiate connections anywhere
they want, as that opens up malicious attack vectors.



SOP = same origin policy

I will phrase this generally for all potential protocols, not just HTTP.

Status quo should remain, where "cookies" (i.e. any client-side persistent
user data) are (at least by default) inaccessible if they were not created
by *.domain of the current page (i.e. window.location.*).

There are only two categories of SOP attacks (all attacks fall under these
two):

1. Cross-domain requests where "cookies" for the domain, receiving the
request, are automatically included in the request.

2. Cross-domain requests that load malicious resources (e.g. usually
scripts) from foreign domain into current domain.

My first point is that #1 can be configured to never happen and thus SOP
would not need to be enforced (instead page scripting can explicitly pass
"cookie" data in requests, and servers can refuse to use any "cookie" data
inserted automatically by the browser). There would be an exception for
pages that don't want to use scripting, and for that exception SOP would
need to be enforced irrespective of what I write below.  Also PHP
programmers should be aware that sessions automatically load cookies (and
besides PHP session ids are apparently hackable, http://samy.pl/phpwn ).

My second point is that SOP also need not be enforced because of #2, if
the user has agreed to trust the current page (domain). This is because
the current page is entirely in control of what is loads. If the current
page decides to load an untrusted script that violates and removes this
control, then the fault/responsibility is the current page (not the
browser and not the bad script). There are numerous ways the user could
express this trust, and the browser should decide its implementation of
that. Pages would need a way to request that the browser turn off SOP. I
would expect that most domains would offer two versions of each page (or
site), one that does not turn SOP off and thus is by default trusted by
all users, and another that turns SOP off and (carefully) adds features
for users who trust the page (or site). The reason that more granularity
for the tradeoff between features and trust, is more secure, is because
the power and wisdom of the free market is enabled and optimized (it is
because of Coase's Theorem[2], see my other example below).

[2] http://www.ietf.org/mail-archive/web/hybi/current/msg03233.html

My third point is that if WebSockets does not use HTTP, then #1 can't
happen because there are no HTTP cookies involved.

My fourth point is that SOP is a centralized "least common denominator" on
tradeoff between features and trust-based security.  Thus it is not the
optimum result for either features or security, because it is not as
granular as it could be.  I have explained above how to practically and
easily make it more granular.

My fifth point is to re-iterate (from my prior posts) the point that
centralized "least common denominator" security has a dead-end at
whitelisted communication everywhere, or failed filtering (I won't say
failed "security" because I don't view the centralized model as secure
because when users are forced to use less features, Coase's Theorem[2]
insures some will route around the barrier/extra cost). I had in past
given the simple example of HTML pages encrypting requests from the
browser over HTTP (port 80) using JavaScript, which would force the
enterprise proxies to either whitelist port 80 or lose their ability to
see the data and filter it.

And let me re-iterate the point[3] from my prior posts in this thread (and
HTTP Compliance), which I assume was ignored by this list, that any
collateral damage _outside_ the domain affected can be trivially erased by
the user with a simple and instantaneous reset of their client machine,
running a disk image restoration engine such as Baseline Shield with an
exception drive/folder for persistant file changes. And this paradigm
travels with the user, unlike the current proxy firewall paradigm of the
enterprise. And that firewall/filtering paradigm has already nearly closed
(whitelisted or eliminated secure communications on) every port except 80
and soon 80 will be forced closed (or the filtering will have a hole), as
per the example I gave in prior paragraph.

[3] http://www.ietf.org/mail-archive/web/hybi/current/msg03277.html