Re: What I am missing

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.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 17:35:11 UTC