Hi Tobias,
Replies inline.
On Mar 3, 2012, at 6:07 PM, Tobias Gondrom wrote:
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 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.
- 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.
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.
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?
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
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
