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
- [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Willy Tarreau
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Willy Tarreau
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Willy Tarreau
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Greg Wilkins
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Greg Wilkins
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Greg Wilkins
- Re: [hybi] New port and Tunneling? Willy Tarreau
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Greg Wilkins
- Re: [hybi] New port and Tunneling? Greg Wilkins
- Re: [hybi] New port and Tunneling? Willy Tarreau
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Willy Tarreau
- Re: [hybi] New port and Tunneling? Greg Wilkins
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Vladimir Katardjiev
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Vladimir Katardjiev
- Re: [hybi] New port and Tunneling? Willy Tarreau
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Adam Barth
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Adam Barth
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Dave Cridland
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Salvatore Loreto
- Re: [hybi] New port and Tunneling? Shelby Moore
- Re: [hybi] New port and Tunneling? Shelby Moore