Re: Hashes.

On Thu, Dec 12, 2013 at 5:06 PM, Garrett Robinson <grobinson@mozilla.com> wrote:
> 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).

This is the unusual case, and we do want the user agent to print all
of these. This requires the developer's attention. Usually the
developer's script should be whitelisted. Any blacklisted script
receives a warning anyway. This proposal just says to include an
actual hash with it.

>
> 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)

That should be up to the user agent to determine. The vast majority of
web developers will just use one hash algorithm for all their inline
scripts. If they use multiple ones, the browser can just default to
the first one they used. This is used for debugging purposes and it
should suffice.

>
>
>> 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.

Hashes are a complicated thing. Get one byte wrong and they can be
screwed up. Here's a few things that can get wrong:
(a) The developer includes more or less whitespace than they should
(b) They use the wrong encoding
(c) They use the wrong case
(d) They apply base64 on the hex value, not the binary value

A debugging message with the actual hash helps out with this, saying
"Hey! This is the hash you should be getting! Fix your hash function
until you get this."

Remember you can't just "Save page as..." you also have to copy the
particular piece of text between <script> and </script> (and many
browsers slightly change your source when you "Save page as..."!)

In addition, for the simplest of websites, the author can just rely on
what the browser is telling them to use an as expected header and
simply copy/paste it from the developer console.

Received on Friday, 13 December 2013 08:13:15 UTC