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
