- From: ☻Mike Samuel <msamuel@google.com>
- Date: Wed, 19 Nov 2014 11:03:05 -0500
- To: Michaela Merz <michaela.merz@hermetos.com>
- Cc: Pradeep Kumar <pradeep.online00@gmail.com>, public-webapps <public-webapps@w3.org>, noloader@gmail.com
Browser signature checking gives you nothing that CSP doesn't as far as the security of pages composed from a mixture of content from different providers. As Florian points out, signing only establishes provenance, not any interesting security properties. I can always write a page that runs an interpreter on data loaded from a third-party source even if that data is not loaded as script, so a signed application is always open to confused deputy problems. Signing is a red herring which distracts from the real problem : the envelope model in which secrets are scoped to the whole content of the envelope, makes it hard to decompose a document into multiple trust domains that reflect the fact that the document is really composed of content with multiple different provenances. By the envelope model, I mean the assumption that the user-agent receives a document and a wrapper, and makes trust decisions for the whole of the document based on the content of the wrapper. The envelope does all of 1. establishing a trust domain, the origin 2. bundles secrets, usually in cookies and headers 3. bundles content, possibly from multiple sources. Ideally our protocols would be written in such a way that secrets can be scoped to content with a way to allow nesting without inheritance. This can be kludged on top of iframes, but only at the cost of a lot of engineering effort. On Wed, Nov 19, 2014 at 10:27 AM, Michaela Merz <michaela.merz@hermetos.com> wrote: > > I don't disagree. But what is wrong with the notion of introducing an > _additional_ layer of certification? Signed script and/or html would most > certainly make it way harder to de-face a website or sneak malicious code > into an environment. I strongly believe that just for this reason alone, we > should think about signed content - even without additional potentially > unsafe functionality. > > Michaela > > > > On 11/19/2014 09:21 AM, Pradeep Kumar wrote: > > Michaela, > > As Josh said earlier, signing the code (somehow) will not enhance security. > It will open doors for more threats. It's better and more open, transparent > and in sync with the spirit of open web to give the control to end user and > not making them to relax today on behalf of other signing authorities. > > On 19-Nov-2014 8:44 pm, "Michaela Merz" <michaela.merz@hermetos.com> wrote: >> >> You are correct. But all those services are (thankfully) sand boxed or >> read only. In order to make a browser into something even more useful, you >> have to relax these security rules a bit. And IMHO that *should* require >> signed code - in addition to the users consent. >> >> Michaela >> >> >> >> On 11/19/2014 09:09 AM, Pradeep Kumar wrote: >> >> Even today, browsers ask for permission for geolocation, local storage, >> camera etc... How it is different from current scenario? >> >> On 19-Nov-2014 8:35 pm, "Michaela Merz" <michaela.merz@hermetos.com> >> wrote: >>> >>> >>> That is relevant and also not so. Because Java applets silently grant >>> access to a out of sandbox functionality if signed. This is not what I am >>> proposing. I am suggesting a model in which the sandbox model remains intact >>> and users need to explicitly agree to access that would otherwise be >>> prohibited. >>> >>> Michaela >>> >>> >>> >>> >>> >>> On 11/19/2014 12:01 AM, Jeffrey Walton wrote: >>>> >>>> On Wed, Nov 19, 2014 at 12:35 AM, Michaela Merz >>>> <michaela.merz@hermetos.com> wrote: >>>>> >>>>> Well .. it would be a "all scripts signed" or "no script signed" kind >>>>> of a >>>>> deal. You can download malicious code everywhere - not only as scripts. >>>>> Signed code doesn't protect against malicious or bad code. It only >>>>> guarantees that the code is actually from the the certificate owner .. >>>>> and >>>>> has not been altered without the signers consent. >>>> >>>> Seems relevant: "Java’s Losing Security Legacy", >>>> http://threatpost.com/javas-losing-security-legacy and "Don't Sign >>>> that Applet!", https://www.cert.org/blogs/certcc/post.cfm?EntryID=158. >>>> >>>> Dormann advises "don't sign" so that the code can't escape its sandbox >>>> and it stays restricted (malware regularly signs to do so). >>> >>> >>> >> >
Received on Wednesday, 19 November 2014 16:03:34 UTC