Re: Hashes.

On 12/12/2013 03:58 PM, Dionysis Zindros wrote:
> On Thu, Dec 12, 2013 at 3:42 PM, Garrett Robinson <grobinson@mozilla.com> wrote:
>> On 12/12/2013 02:11 PM, Dionysis Zindros wrote:
>>>
>>> Thanks for your feedback. I'm incorporating the requested changes in
>>> the attached patch.
>>
>>
>> The only other problem I see with this patch is requesting we print the
>> "correct" hash value if a hash values to validate. There's no way to
>> determine which inline script an incorrect hash was intended to whitelist,
>> so they only solution here is to print the hash of every inline script (for
>> every incorrect hash-source in the policy, unless you wanted to add some
>> special-case logic to only print them out for the first hash-source that
>> failed to validate).
>
> No, the proposed change in the spec says that agents should print the
> actual, not the expected, script hash (see definition above). That is,
> the hash printed is that which the browser evaluated for the inline
> script and which didn't match the one on the HTTP header. For example,
> if the header specifies 3 different hashes sha256-A, sha256-B, and
> sha256-C, and the inline script is "xxx", then the browser should
> print base64(sha256(xxx)) - not A, B, or C.

If the page only has one inline script, "xxx", then - sure. What if it 
has n blocked inline scripts? Then you need to print 
base64(sha256(inline-script-x)) for x in range(1,n).

Implementing this would be non-trivial.

> If the wording does not make that clear, I'd be happy to modify it
> with clarifications.
>
> The only thing that remains unclear is which algorithm the browser
> should be using here, out of the ones it supports. Perhaps a
> clarification is needed for this. However, as most web authors will be
> using a single algorithm each (e.g. SHA256), this will only yield one
> entry in the developer console based on what the web author is using
> on their headers.

It is not at all clear what to do if the same header uses multiple 
hashing algorithms, besides hash each possible inline resource with each 
possible hash value. More clutter. (although I agree it is likely most 
web authors will use the same hash value for all of their inline resources)

> The idea is that the developer should be able to understand what the
> browser expects to see in the HTTP headers during debug, to fix the
> HTTP headers accordingly. Outputting the HTTP header hash in the
> console doesn't help - the HTTP header can already be viewed by the
> developer, so there's no point in that. The point is to reveal what
> the browser thinks the hash of the blocked inline script is, so that
> the developer can put that in the header to whitelist their script
> easily.

I am not totally against this idea, I am just not convinced that it 
useful enough/worth the effort to be implemented in the browser. If I 
were a developer having trouble verifying hashes, I would just Save Page 
As... and run a script on the source or something like that.

Received on Friday, 13 December 2013 01:07:17 UTC