W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2013

Re: Updated script hash proposal (non spec text)

From: Joel Weinberger <jww@chromium.org>
Date: Wed, 11 Dec 2013 14:27:03 -0800
Message-ID: <CAHQV2Kng+ouYR0LL4uvYj2uWFtSpii=Jy+XeJLM==PD8vi6gpA@mail.gmail.com>
To: Garrett Robinson <grobinson@mozilla.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, Dec 10, 2013 at 3:21 PM, Garrett Robinson <grobinson@mozilla.com>wrote:

> However, when building this, I couldn't find the script-hash grammar
>> on the CSP 1.1 spec. Are there any plans to update the draft soon?
>> It's hard to get working examples without a spec - one has to dig
>> into the individual browser source code to see how things are done.
>>
>
> A proposed patch to specify nonce-source and hash-source is just waiting
> on a merge (I sent a reminder).
>
>
>  I recommend that we specify SHA256/384/512 on the spec and drop SHA1
>> completely. There are no backwards compatibility issues here, so
>> there is no need to support a hash function which might not be
>> collision-resistant.
>>
>
> That patch only allows sha256/384/512.
>
 SGTM. I implemented SHA1 because that's the only hashing function Blink
has support for right now, and it was the path of least resistance. I'm
happy to implement the others if that's what we decide on (and I'm happy to
dump SHA1 as well).

>
> -Garrett
>
>
> On 12/10/2013 03:16 PM, Dionysis Zindros wrote:
>
>>
>>
>>
>> On Tue, Dec 10, 2013 at 2:55 PM, Garrett Robinson <grobinson@mozilla.com
>> <mailto:grobinson@mozilla.com>> wrote:
>>
>>     On 12/10/2013 02:51 PM, Neil Matatall wrote:
>>
>>         Just wanted to point out an example of this in the wild
>>         http://dionyziz.logimus.com/__content-security-policy/
>>
>>         <http://dionyziz.logimus.com/content-security-policy/>
>>
>>
>>     Awesome! The Firefox WIP is almost ready to land too. One thing - we
>>     only support sha256/384/512, due to well known concerns with SHA1's
>>     collison resistance. This example is using sha1, which it says is
>>     the only algorithm Chrome supports at the moment. Do we want to spec
>>     the supported algorithms for 1.1?
>>
>>
>> I'll update the example to add test cases for SHA256/384/512. By the
>> way, I moved it to an HTTPS/HSTS URL to illustrate good practices, as
>> CSP builds on the assumption that HTTP headers cannot be tampered with:
>>
>> https://dionyziz.com/content-security-policy/
>>
>> However, when building this, I couldn't find the script-hash grammar on
>> the CSP 1.1 spec. Are there any plans to update the draft soon? It's
>> hard to get working examples without a spec - one has to dig into the
>> individual browser source code to see how things are done.
>>
>> I recommend that we specify SHA256/384/512 on the spec and drop SHA1
>> completely. There are no backwards compatibility issues here, so there
>> is no need to support a hash function which might not be
>> collision-resistant.
>>
>> So, let's update the CSP 1.1 draft to add the grammar for this.
>>
>>
>>         Check out
>>         http://dionyziz.logimus.com/__content-security-policy/csp-__
>> js.php
>>
>>         <http://dionyziz.logimus.com/content-security-policy/csp-js.php>
>>         in Chrome canary with experimental flags set :)
>>
>>
>>
>>         On Tue, Dec 3, 2013 at 1:41 PM, Garrett Robinson
>>         <grobinson@mozilla.com <mailto:grobinson@mozilla.com>> wrote:
>>
>>             Attached updated patch to
>>
>>             1. create a "base64-value" rule so we don't have to repeat
>>             ourselves in
>>             separate "nonce-source" and "hash-source" rules
>>             2. limit ='s to be a max of 2 and only allowed at the end of
>>             the string
>>
>>             Alternatively, might we just refer to "base64 string from
>>             RFC 3548" [0],
>>             the way we do for the "scheme" rule?
>>
>>             [0] http://tools.ietf.org/html/__rfc3548.html#section-3
>>
>>             <http://tools.ietf.org/html/rfc3548.html#section-3>
>>
>>             -Garrett
>>
>>             On 11/26/2013 10:57 AM, Joel Weinberger wrote:
>>
>>                 I, too, support the second option as well (and, in fact,
>>                 that is how
>>                 we've implemented it for hashes in Chrome).
>>
>>                 I don't suppose there's a way to specify that the '='
>>                 should only appear
>>                 at the end of the value (and there should be 2 or less)?
>>                 --Joel
>>
>>
>>                 On Mon, Nov 25, 2013 at 11:09 AM, Garrett Robinson
>>                 <grobinson@mozilla.com <mailto:grobinson@mozilla.com>
>>                 <mailto:grobinson@mozilla.com
>>
>>                 <mailto:grobinson@mozilla.com>>__> wrote:
>>
>>                       On 11/25/2013 01:24 PM, Neil Matatall wrote:
>>                       > Ah yes. Oops. I support the second option as well.
>>                       >
>>                       > Should "1*( ALPHA / DIGIT / "+" / "/" / "=" )"
>>                   be its own
>>                       > symbol/definition/whatever to make it clear that
>>                 the values will have
>>                       > the same rules?
>>
>>                       I was thinking of doing that, but wasn't sure how
>>                 to write it in the
>>                       spec. Can we just call it base64-value?
>>
>>
>>
>>
>>
>
Received on Wednesday, 11 December 2013 22:27:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 December 2013 22:27:32 UTC