Re: [MIX] Feedback on the private origin & self-signed certificate requirements

Mike,

 I hate to recapitulate the extensions debate we had for CSP, but I wonder if you've thought about whether we ought to have some (non-normative) language about this kind of thing when the JS global environment is an extension?  

  The case of calling directly from the browser to another application's web server seems nefarious, but I know that it's a very common thing (at least in my technical circles, if not numerically in the store) for Chrome extensions to make use of localhost web servers or web sockets to connect web apps to other interesting things.  

  Or do you think that browser vendors will just make their own appropriate decisions on this without guidance, like how, e.g. Chrome extensions can talk in a limited fashion to USB devices but ordinary web pages cannot.

-Brad


On Sep 14, 2014, at 5:23 AM, Mike West <mkwst@google.com> wrote:

> Hi Zhigao!
> 
> On Sun, Sep 14, 2014 at 6:22 AM, Chen, Zhigao <zhigao.chen@sap.com> wrote:
> 1. Can we relax the first requirement to allow requests to a private origin over loopback interface? I think it is better to leave the cloud application to decide what origins are allowed and disallowed by using CSP. Section 5.4 treats 127.0.0.1 as an authenticated origin.
> 
> I think the loopback interface might be a reasonable exclusion. CCing cbentzel@, as I just had a similar conversation with him at the end of last week, and Brian Smith, who I suspect will have opinions.
> 
> That said, there are certainly abuses of this functionality that I think it would be good to limit: see https://groups.google.com/a/chromium.org/d/msg/net-dev/oyUB2bWKGuE/k0ZWtmnJ_lcJ for an example of a (large) public website using local applications to bypass geolocation permission checks.
> 
> It sounds like your use-case would be met with a requirement that localhost be authenticated with a self-signed certificate in the browser's local trust store. That would at least make it clear that the installed application was asserting control over the machine in a way that the browser is explicitly excluded from defending against.
> 
> WDYT?
> 2. Self-signed certificates are commonly used in corporates. This can be a big impact. Since a user already grant the trust by manually importing the certificate into his browser trusted store, does browser have to be so restrictive? I can't use a real certificate, since "localhost" is not a fully qualified Common Name.
> 
> In this case, the enterprise should assert control over the machines which ought to trust the certificates by installing a root certificate into the local trust stores. The intent of this section was not to outlaw self-signed certificates entirely, but only those which don't chain to a root in the local trust store. I've updated the text accordingly: https://github.com/w3c/webappsec/commit/f86ae7a329cd64b19b66b0ef4e74a6df23daf33e
> 
> I hope that leaves enough room for the use-case you're outlining here.
> 
> --
> Mike West <mkwst@google.com>
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
> 
> Google Germany GmbH, Dienerstrasse 12, 80331 M�nchen, Germany
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Gesch�ftsf�hrer: Graham Law, Christine Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>

Received on Monday, 15 September 2014 16:00:27 UTC