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

Hi Mike,

Thanks for your comments. Good to hear others’ opinions, too. Adding a pre-condition of authenticating localhost looks good to me. And thanks for clarification in the changed texts!


Regards,
Zhigao

From: Mike West [mailto:mkwst@google.com]
Sent: Sunday, September 14, 2014 8:23 PM
To: Chen, Zhigao; Chris Bentzel; Brian Smith
Cc: public-webappsec@w3.org
Subject: Re: [MIX] Feedback on the private origin & self-signed certificate requirements

Hi Zhigao!

On Sun, Sep 14, 2014 at 6:22 AM, Chen, Zhigao <zhigao.chen@sap.com<mailto: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<mailto:mkwst@google.com>>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91<tel:%2B49%20162%2010%20255%2091>
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.)