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

From: Yoav Nir <[email-masked]>
Date: Fri, 3 Feb 2012 00:54:39 +0200

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

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 23 Feb 2012 11:26:29 +1100

> 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

---

From: Gervase Markham <[email-masked]>
Date: Thu, 23 Feb 2012 14:47:28 +0000

> https://c.sslvpn.example.com/stuff

This would be much better. It would still allow the sites in some 
circumstances to maliciously mess with each other's cookies if they chose.

I'm not entirely familiar with VPN technology, but if it were possible 
for VPNs everywhere always to use the same domain name for this purpose, 
e.g. vpn.example, then we could add *.vpn.example to the Public Suffix 
List and get at least some sort of protection between subdomains. Or 
even code in "strip off this prefix before doing domain calculations" 
support into clients.

Just ideas :-)

Gerv

---

From: Yoav Nir <[email-masked]>
Date: Thu, 23 Feb 2012 16:58:43 +0200

Hi James, thanks for reviewing.

The scheme that you propose (a.sslvpn.example.com<http://a.sslvpn.example.com>, b.sslvpn.example.com<http://b.sslvpn.example.com>, etc.) really does work. In fact, the product that my company makes offers this as an option.

Sadly, our customers don't like it, hence the other option.  Using multiple FQDNs requires them to either buy multiple certificates, or a wildcard certificate, both options are more expensive. Additionally this requires them to add multiple DNS records, which for some reason they find cumbersome.

About your other comments:

1) (no need for multiple headers) I agree. I think I will change this in -01. I don't really think stacking portals is a good engineering idea. I just added this for completeness, and I can replace it with text along your comment

2) I don't see that it makes much of a difference. I can do it either way. Can you explain what is the advantage of this over the pseudo-fragment format?

Thanks

Yoav

Yoav,

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 24 Feb 2012 10:35:00 +1100

> The scheme that you propose (a.sslvpn.example.com<http://a.sslvpn.example.com>, b.sslvpn.example.com<http://b.sslvpn.example.com>, etc.) really does work. In fact, the product that my company makes…

Good to hear.

> Sadly, our customers don't like it, hence the other option.  Using multiple FQDNs requires them to either buy multiple certificates, or a wildcard certificate, both options are more expensive. Addi…

Not sure that that is a good enough reason to introduce extended origins.

> 2) I don't see that it makes much of a difference. I can do it either way. Can you explain what is the advantage of this over the pseudo-fragment format?

No big advantage. A pseudo-sub-domain hints at the better approach (using actual sub-domains). It matches the existing syntax (which probably simplifies some code).

--
James Manger

---

From: Yoav Nir <[email-masked]>
Date: Sun, 26 Feb 2012 14:14:07 +0200

Good to hear.

I checked the products of some of our competitors, and they seem to also offer both options. IMHO the cost and complexity of deployment for the user are valid considerations for engineering.

In this case, the cost is incurred not because of technical necessity but because of the way browsers work with commercial CAs - that wildcard certificates are more expensive, and multiple certificates are also more expensive.  Regardless, the cost and complexity are real.

I hope to have a -01 draft ready in time, which will address your other point.

Thanks again for the review

Yoav

---

From: Adam Barth <[email-masked]>
Date: Sun, 26 Feb 2012 09:53:34 -0800

2012/2/26 Yoav Nir <[email-masked]>:
>> The scheme that you propose (a.sslvpn.example.com, b.sslvpn.example.com,
>> etc.) really does work. In fact, the product that my company makes offers
>> this as an option.
>
> Good to hear.
>
>> Sadly, our customers don't like it, hence the other option.  Using
>> multiple FQDNs requires them to either buy multiple certificates, or a
>> wildcard certificate, both options are more expensive. Additionally this
>> requires them to add multiple DNS records, which for some reason they find
>> cumbersome.
>
> I checked the products of some of our competitors, and they seem to also
> offer both options. IMHO the cost and complexity of deployment for the user
> are valid considerations for engineering.
>
> In this case, the cost is incurred not because of technical necessity but
> because of the way browsers work with commercial CAs - that wildcard
> certificates are more expensive, and multiple certificates are also more
> expensive.  Regardless, the cost and complexity are real.
>

Frankly, your proposal is very unlikely to be implemented.  The
engineering effort required to implement is quite large, if it's even
possible.  Consider, for example, that beyond just changing the
browser, you'd also need to change Flash, Java, and every other
plug-in that implements the same-origin policy.

In addition to that complexity, there are many assumptions in browsers
and in the software that surrounds browsers that origins are
determined by URL.  Your proposal breaks that assumption.

Adam