Re: [websec] I-D Action: draft-nir-websec-extended-origin-00.txt

"Manger, James H" <James.H.Manger@team.telstra.com> Thu, 23 February 2012 00:26 UTC

Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3CC21F85EC for <websec@ietfa.amsl.com>; Wed, 22 Feb 2012 16:26:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.638
X-Spam-Level:
X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[AWL=-2.338, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGvGwDsmTJcP for <websec@ietfa.amsl.com>; Wed, 22 Feb 2012 16:26:36 -0800 (PST)
Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD1C21F85E3 for <websec@ietf.org>; Wed, 22 Feb 2012 16:26:34 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.73,466,1325422800"; d="scan'208,217"; a="63340635"
Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 23 Feb 2012 11:26:34 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6628"; a="51780509"
Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcdvi.tcif.telstra.com.au with ESMTP; 23 Feb 2012 11:26:32 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Thu, 23 Feb 2012 11:26:31 +1100
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Yoav Nir <ynir@checkpoint.com>, IETF WebSec WG <websec@ietf.org>
Date: Thu, 23 Feb 2012 11:26:29 +1100
Thread-Topic: I-D Action: draft-nir-websec-extended-origin-00.txt
Thread-Index: Aczh/aUIQO/LIhDuQAuf+kjfsK/BIAPvz+Fg
Message-ID: <255B9BB34FB7D647A506DC292726F6E114EC261141@WSMSG3153V.srv.dir.telstra.com>
References: <20120202220021.31936.37346.idtracker@ietfa.amsl.com> <C35E9FBD-8AF7-4F63-B798-1316B985E032@checkpoint.com>
In-Reply-To: <C35E9FBD-8AF7-4F63-B798-1316B985E032@checkpoint.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114EC261141WSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: Re: [websec] I-D Action: draft-nir-websec-extended-origin-00.txt
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Feb 2012 00:26:37 -0000

>> Title           : A More Granular Web Origin Concept
>> Filename   : draft-nir-websec-extended-origin-00.txt


> I have just submitted this draft. The purpose of this is to address the case where a single portal hides several real servers behind it, by translating their URLs into URL that seem to be from that server.
>
> In that case the same origin policy is not enforced correctly, because cookies and scripts from one server behind the portal (for example, a mail server) can be shared and can affect pages form another server behind the same portal.
>
> This draft proposes a header that will tell the client (browser) what the real origin is, and allow the client to apply the SOP.


Yoav,

SSL VPNs that proxy a whole bunch of web sites via a single host are indeed a security problem as they break the same-origin protections that the individual web sites expect. However, I don’t think this draft’s solution is the best approach. It requires browsers to fix what SSL VPN’s have broken; and doesn’t provide much improvement until the new functionality is implemented in all browsers and deployed to most users.

Wouldn’t it be better for SSL VPNs to use lots of sub-domains? For instance, to map internal sites to:
 https://a.sslvpn.example.com/webmail
  https://b.sslvpn.example.com/wiki/index.html
  https://c.sslvpn.example.com/stuff


If the “Extended-Origin” HTTP header approach does proceed…

1] You don’t need multiple Extended-Origin headers for successive portals in a path. A portal about to insert a header can just take into account any existing value if present. That is, insert a single Extended-Origin response header that is unique for each combination of {original-domain; original-extended-origin-header-value}.

2] I think it would be better to serialize an extended-origin as an additional sub-domain, not a fragment. The sub-domain could have a prefix so it cannot (or is highly unlikely to) clash with a real sub-domain. Example:
→ GET https://sslvpn.example.com/xyz
← Extended-Origin: asdhgasghd
→ Origin: https://xb--asdhgasghd.sslvpn.example.com



--
James Manger