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

[Yoav Nir <[e-mail]>]

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

On Feb 23, 2012, at 2:26 AM, Manger, James H wrote:

>> 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