Re: SRI fail open behaviour

At this point, I think we'd really like to go to Candidate Recommendation.

We have two implementations shipping or nearly so, and I don't see any
indication that any implementers are interested in making further changes
beyond failing closed if CORS mode is not specified.  That being the case,
any spec changes would have to be marked as AT RISK and likely backed out
in a few months anyway in order to advance the spec.

Failing open on unknown algorithms still seems to be the closest thing to
consensus, and is what is in the spec and implementations currently agree
on as a way to keep possibilities open for future syntax.

I think the door remains open for user agents to complain loudly on the
console in the event of unrecognized prefixes, or even to look at telemetry
and exercise a prerogative to "recognize" (with a warning) a few formats
outside of the strict productions specified in CSP2 if they appeared in any
abundance,  (e.g. sha-256: or sha-256-) but it would probably be less than
ideal to propagate such practices formally in the specification.

-Brad

On Tue, Jul 28, 2015 at 11:55 AM Brian Smith <brian@briansmith.org> wrote:

> On Mon, Jul 27, 2015 at 5:36 PM, Joel Weinberger <jww@chromium.org> wrote:
>
>>    1) Should crossorigin=anonymous be implicit in all requests (unless
>> same-origin or explicitly set by the developer?
>>    2) Should it fail closed on bad hash algorithms as well?
>>
>> To (1), there doesn't appear to be consensus (although notably I believe
>> all of the editors agree it should *not* be implicit). I'm not sure how to
>> resolve this at this point, so any suggestions would be welcome. My thought
>> is that since this would be an additional "feature," we should default to
>> not include it if we can't come to consensus, but I'm biased since I don't
>> want it anyway :-)
>>
>
> I agree with the editors that it shouldn't be implicit. Follow the
> principle of least surprise: Why would adding an integrity attribute
> automatically change anything about CORS? The default value of the
> |crossorigin| security attribute was chosen to be the most secure value.
> Adding another security attribute shouldn't automatically reduce the
> security of another security attribute.
>
>
>> To (2), again, Brian doesn't appear to agree with this, but I believe
>> that we actually already came to consensus on failing open for an unknown
>> algorithm quite some time ago, and I feel strongly that this decision
>> should remain: http://www.w3.org/2015/02/23-webappsec-minutes.html#item07
>>
>
> I think you and I agree more than we disagree. Web developers have to take
> into account that some browsers might not support the SRI digest that they
> use. That includes the case where the browser doesn't support SRI at all.
> For some reason people argue that developers should only have to properly
> deal with the case where the browser doesn't support SRI at all.
>
>
>> I think Francois's point is correct as well. It is possible to download
>> every browser possible to test your page on, but in practice it won't
>> happen, and one of the worst things the integrity attribute can do would be
>> break otherwise functional pages.
>>
>
> [Sorry for the lack of brevity. Note that at the end, I make a proposal
> that attempts to find a compromise.]
>
> The whole point of SRI is to break pages when expectations are not met.
> The same with TLS and other security features. It isn't reasonable for
> anybody to expect their pages to work in older browsers without testing
> them in older browsers, *especially* when they are using the security
> features like SRI and CSP that this working group creates or even TLS. So
> the whole concern of protecting against breaking pages in older browsers is
> invalid, IMO.
>
> There are three use cases for SRI that I see:
>
> 1. I want to do <script src=
> https://social-network.example.com/track-my-users.js> without allowing
> the social network's JS to do harmful things in the event that the social
> network is hacked. This is actually what <iframe sandbox> is for, but the
> companies running the trackers don't want to be put into <iframe sandbox>
> yet, so people are trying to use SRI instead.
>
> 2. Consider a big company (like Google) that has multiple levels of CDNs.
> The lowest-latency "edge" CDNs are machines within data centers of third
> parties like ISPs. The next level of CDN is operated from within their own
> data centers, but it generally has higher latency because the internal data
> centers are further away than the ISPs' points of presence. The main
> document gets loaded from the internal CDN. If the browser supports SRI,
> then the main document will have <script src> elements pointing at the edge
> CDNs, otherwise it will have <script src> pointing at the internal CDN.
>
> 3. The website wants to use a third-party CDN like
> https://code.jquery.com/. It wants to protect users of modern browsers
> from being hacked through that CDN, but it doesn't want to bother to do
> anything to protect users that uses browsers that don't implement SRI with
> secure algorithms.
>
> Now, the problematic scenario we are concerned about requires SHA-2 to be
> broken, right? Otherwise, nobody would bother switching to SHA-3 without
> also providing SHA-2 digests too. Now, what kind of cryptographic break is
> likely to affect SHA-2 in a way that affects any of these scenarios?
> Basically, collision attacks are the only ones that are even close to being
> feasible, as far as we know (even for MD5).
>
> For scenerio #3, a collision attack require the authors of the JS code
> being loaded to carefully construct two versions of their JS code that have
> a SHA-2 collision, publish the good version on their CDN, wait for people
> to update their links to use it, and then replace it with the bad version,
> without anybody noticing in any other way. It doesn't seem like a very
> realistic scenerio.
>
> For scenerio #1 and #2, the attacker would have to be part of the internal
> organization. In that case, you have much bigger problems.
>
> Keep in mind that we're nowhere close to breaking SHA-2 in any way, so it
> is very unlikely that SHA-3 will be needed by anybody for SRI within the
> next several years. See, for example,
> http://security.stackexchange.com/a/21116.  If browsers that support SRI
> simply implement SHA-3 soon, the whole problematic scenario becomes even
> more improbable.
>
> So, with all that in mind, it doesn't make sense to me that a simple typo
> like "sha256:..." instead of "sha256-..." should be enough to destroy the
> security of a page in any of the three scenarios above, to avoid a
> problematic case for scenario #3 that is unrealistic. Typos happen every
> day. The variety of syntaxes for SRI that this group has already cycled
> through ("sha-256:", "ni://...", "sha256-", etc.) is pretty good evidence
> of the likelihood of people making such mistakes.
>
> Consequently, I still think the best thing to do is to just make SRI fail
> closed if there is any problem (parsing or otherwise) with enforcing SRI.
>
> However, if people are unwilling to do that, how about this compromise: If
> the browser encounters an integrity attribute that only contains digests
> prefixed with "sha[3-9]-[0-9][0-9][0-9]-", then it should fail open;
> otherwise it should fail closed. This will allow, for example, "sha3-256-"
> and "sha3-512".
>
> To be clear, I think that's silly, but better than the current fail open
> logic.
>
> Cheers,
> Brian
> --
> https://briansmith.org/
>
>