Jonas Sicking wrote:
On Mon, May 10, 2010 at 6:38 PM, Bjoern Hoehrmann <derhoe...@gmx.net> wrote:
* Nathan wrote:
If you do not depend on a user's special standing with a third party
site, you can configure your server as proxy between your user and the
third party site. That's more difficult for you, but easier for users
and maintainers of third party sites. If we'd do away with the access
restriction, it'd be easier for you, and more difficult for users and
third parties. What we have now is largely due to following the path
of least resistance (which is probably true for most web technology).
Is it possible to set up a server as a proxy, where a client side ssl
certificate is also proxied through, should the server at the address
being proxied request one?
If there is a special relationship between the user and the third party
site, your site would similarily have to have a special relationship
with at least one of them (for example, you might need the user's certi-
ficate). In essence, in this scenario, the third party restricts access
to those who can prove a certain identity; since you are not them, you
cannot do that. This would be a rather broken scenario though, on the
one hand you cannot directly access the third party server because you
lack some user's certificate; on the other hand, you do have access to
it if your server proxies the access over the user's browser (if there
were no access restrictions in place, be those default rules or "CORS"
rules or something along those lines). That is largely the problem that
is sought to be avoided here.
For what it's worth, my main concern isn't IP based authentication
between different 3rd parties.
My main concern is corporate firewalls which allow users sitting
inside the firewall to access content on intranet servers, while
preventing outside parties from even sending IP packets that reach
those intranet servers.
A browser running on a computer inside the firewall must not allow
external sites to access the internal servers, effectively using the
browser as a proxy to circumvent the firewall. If a browser allowed
that I suspect it would become very unpopular. Rightly so in my
opinion.
Sigh, it looks like there is no way around this other than to use CORS,
thus if I may ask 3 things for consideration:
1: Provide servers with the option of placing a domain wide CORS policy
in a .well-known directory
2: Implement a user UI confirmation screen to allow JS applications xhr
access to other origin resources. (Similar to the allow desktop
notifications scenario in chromium)
3: Standardise a way of having signed scripts that are trusted (like
mozilla have implemented)
Ideally, a long term shift towards global access unless denied by CORS
would be an ideal solution (imo), typically corporate sys admin's will
be a bit more up to speed when it comes implementing security features
than joe public, and quite sure that a security bulletin + a bit of
coverage around the web would get the information in to the right hands
(from the ua vendors, large tech sites, more social techcrunch/rww type
sites etc). Whereas no amount of media coverage will ever inform the non
professional web population that they have to add these headers to their
resources (let alone them actually doing it).
Surely we can't be dependent on CORS indefinitely, perhaps some form of
planned path as to how CORS might be phased out? [one day restful https
web access control will be the norm and the need for CORS removed].
Aside: do any of you know where I'd be best to suggest the possibility
of having in browser NSS methods available to javascipt to sign,
encrypt, decrypt data using client side certificates / remote public keys?
Best,
Nathan
