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

From: Tobias Gondrom <[email-masked]>
Date: Sat, 03 Mar 2012 16:07:31 +0000

Hello Yoav,

thank you for the interesting draft.

<hat="individual">

I have a few points as feedback:
- the 3-tupel of origin consists of "real" parameters (protocol, URL, 
port), while the introduction of the 4th tupel feels like an artificial 
parameter extension as it is not mapped to anything visible to the 
client and in fact will be spliced by the middle-server (vpn server). 
This makes me very hesitant, whether this would be a good idea.

- As Adam mentioned that there will be migration problems.
At the moment all browsers and other systems operate on the SOP with 
3-tupel to compare for identity. It will be difficult (read: near 
impossible) to enforce that all deployed systems out there shall from 
now on be compliant with a 4-tupel and no longer assume identity of two 
sites when only the first three parameters are equal.

So, although I agree that economic reasons are absolutely viable reasons 
for such an idea, I have concerns that this draft is only a workaround 
for certain closed areas (i.e. where a company can basically enforce 
that all accessing clients are in fact updated using such a 4-tupel 
policy) but will create severe consistency issues in the Internet where 
you would then see a mix of 3-tupel and 4-tupel clients, with the risk 
of messing up the predictability of handling of SOP.

Maybe a question regarding the use cases:
As in general, systems use sub-domains for such purpose (as explained by 
you and James), I am wondering whether there are other scenarios (beyond 
VPN) that may need this 4th origin parameter?

Best regards, Tobias

On 02/02/12 22:54, Yoav Nir wrote:
> Hi
>
> 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.
>
> If people find this interesting, I would like to discuss this in 
> Paris. Any comments will be greatly appreciated.
>
> Yoav
>
> Begin forwarded message:
>
>> *From: *"[email-masked] <mailto:[email-masked]>" 
>> <[email-masked] <mailto:[email-masked]>>
>> *Subject: **I-D Action: draft-nir-websec-extended-origin-00.txt*
>> *Date: *February 3, 2012 12:00:21 AM GMT+02:00
>> *To: *"[email-masked] <mailto:[email-masked]>" 
>> <[email-masked] <mailto:[email-masked]>>
>> *Reply-To: *"[email-masked] 
>> <mailto:[email-masked]>" <[email-masked] 
>> <mailto:[email-masked]>>
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>>
>> Title           : A More Granular Web Origin Concept
>> Author(s)       : Yoav Nir
>> Filename        : draft-nir-websec-extended-origin-00.txt
>> Pages           : 8
>> Date            : 2012-02-02
>>
>>   This document defines an HTTP header that allows to partition a
>>   single origin as defined in RFC 6454 into multiple origins, so that
>>   the same origin policy applies among them.
>>
>>   The header introduced in this document allows the portal to specify
>>   that resources that appear to be from the same origin should, in
>>   fact, be treated as though they are from different origins, by
>>   extending the 3-tuple of the origin to a 4-tuple.  The user agent is
>>   expected to apply the same-origin policy according to the 4-tuple
>>   rather than the 3-tuple.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-nir-websec-extended-origin-00.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-nir-websec-extended-origin-00.txt
>
>
>
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Yoav Nir <[email-masked]>
Date: Mon, 5 Mar 2012 01:05:16 +0200

Hi Tobias,

Replies inline.

> This makes me very hesitant, whether this would be a good idea.

As far as the client is concerned, there is only one server. If that server does not give any hints to the client, it's going to treat all these different resources as belonging to the same origin. So it does map to something the server sends.

> of messing up the predictability of handling of SOP.

Actually, SSL VPNs are deployed where the company has no control over the clients. Sure you can enforce that users only use one kind of browser, but typically SSL VPNs are deployed so as to support any type of client, from phones to desktop. Companies that have that level of control tend to equip their employees with laptops that run IPsec VPNs. 

However, these SSL VPN portals exist today, and hide multiple servers behind a single hostname and port. Typically these will be mostly internal servers with a few external ones. For example, our deployment has the mail server (OWA), the internal Wiki, The automated build system, the SAP web application, and the web application of an external service provider that delivers lunch. These are not just random sites on the Internet, but specific servers that the administrator has chosen. The way these are deployed now, the lunch service provider can steal the cookies from the mail server, or script it. Having the SSL VPN server provide this extra information might help security (if the browsers use that information). It won't make it worse.

> VPN) that may need this 4th origin parameter?

I guess any HTTP reverse proxy may hide multiple servers behind it. Reverse proxies are used for caching, load balancing, access control to web application. Even CDNIs are a type of reverse proxy. I believe that SSL VPNs are a little different. The other types of reverse proxy are typically installed and maintained by experts. SSL VPNs are installed and maintained by people whose knowledge of networking can range from "NOC team material" to "the CEOs nephew who's really good with computers". So I think all reverse proxies could benefit from a 4th origin parameter, but I think most of the others can work around that need, while some SSL VPN customers can't.

Yoav