Yes - it establishes provenance and protects against unauthorized
manipulation. CSP is only as good as the content it protects. If the
content has been manipulated server side - e.g. by unauthorized access -
CSP is worthless.
Michaela
On 11/19/2014 10:03 AM, ☻Mike Samuel wrote:
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.m...@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.m...@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.m...@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.m...@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).
