Re: What I am missing

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