W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2015

Re: SRI fail open behaviour

From: Brian Smith <brian@briansmith.org>
Date: Sat, 18 Jul 2015 13:44:31 -0400
Message-ID: <CAFewVt51_drHpuzgLFAOJT=nNWXv1v=tF81AKY+Mvep76+AuVg@mail.gmail.com>
To: Francois Marier <francois@mozilla.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Francois Marier <francois@mozilla.com> wrote:

> The main downside I see to failing closed in that case is that we would
> treat old SRI-enabled browsers worst than old non-SRI-enabled browsers.
> For example, in the future if you have:
>   <script integrity="sha3-Gk5l2Bi..." crossorigin="anonymous">
> - Chrome 80 will load this just fine because it implements "sha3"
> - IE 9 will load it too because it doesn't have support for SRI at all
> - Firefox 42 would block it because it supports SRI but not sha3

All three would be doing the right thing. The web page is saying "I don't
trust the server. I would rather have the load fail than have you load
content that doesn't have a SHA-3 hash of 'Gk5l2Bi....'." If the page
author wanted Firefox 42 to be able to load the page, then they would test
in in Firefox 42, see that it doesn't work, and then either add a SHA-2
hash or decide that SHA-2 is too unsafe to rely on.

>From a usability standpoint, it is hard to see why a developer would add an
integrity attribute at all unless they want the fail-closed behavior. It's
much harder to write a proper test that every integrity attribute has the
correct syntax. However, it is pretty easy to notice when your JS code
doesn't run because a typo in the integrity attribute blocked the load.

Note that [MIX] has fail-closed behavior: if you make a typo "http://"
instead of "https://" then the resource does not load.

> Perhaps a set of options that are not related to hash-expressions might
> > be useful to fail close here or another attribute like:
> > 'integrity-violations="throw-always"' (This could be a level 2 thing
> > perhaps)
> That would be an interesting thing to explore in V2 along with CSP
> directives that would require that all subresources be protected with SRI.

It would be simpler and consequently better to just make fail-closed the
default with no way to override it.

Any SHA-2 -> SHA-3 transition is very unlikely to cause the type of
problems that motivated the fail-open behavior. People are not rushing to
implement, deploy, or use SHA-3. (One of the surprising results of the
SHA-3 competition was that SHA-2 doesn't seem so bad after all.) On the
other hand, every web developer makes typos every day, and it would be nice
to help them out.

Received on Saturday, 18 July 2015 17:44:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:50 UTC