- From: Brian Smith <brian@briansmith.org>
- Date: Sat, 18 Jul 2015 13:44:31 -0400
- To: Francois Marier <francois@mozilla.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAFewVt51_drHpuzgLFAOJT=nNWXv1v=tF81AKY+Mvep76+AuVg@mail.gmail.com>
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. Cheers, Brian
Received on Saturday, 18 July 2015 17:44:59 UTC