Re: [SRI] may only be used in documents in secure origins

On Mon, Nov 3, 2014 at 9:32 AM, Frederik Braun <fbraun@mozilla.com> wrote:

> There is a clear benefit in doing SRI on a document delivered over an
> unauthenticated origin, I agree.
> SRI over HTTP is making the situation a bit safer than no SRI at all.
>
As will probably come as a surprise to no one, I disagree :-) Given that
over HTTP there is no guarantee whatsoever that the integrity you've
received is the integrity the site intended to give you, enforcing the
integrity gives a completely false sense of security to the developer and
user. HTTPS is the security boundary of the Web, as flawed as it might be,
and it must be assumed that anything not delivered over HTTPS is
compromised.

>
> Although it would be desirable for every site to use HTTPS,
> I don't think that SRI is the right way of promoting this.
>
This isn't a matter of promoting HTTPS; it's a matter of suggesting to
users and developers that they're getting a security property that they're
simply not getting.

>
> (I feel like I have anticipated this thread
> https://github.com/w3c/webappsec/pull/74#)
>
> ----- Ursprüngliche Mail -----
> > Von: "Pete Freitag" <pete@foundeo.com>
> > An: public-webappsec@w3.org
> > Gesendet: Montag, 3. November 2014 18:01:43
> > Betreff: [SRI] may only be used in documents in secure origins
> >
> > Hi Folks,
> >
> > I was playing around with SRI in Chrome Canary (40.0.2208.0). When my
> test
> > document was loaded over HTTP/80 I get the error:
> >
> > "The 'integrity' attribute may only be used in documents in secure
> origins."
> >
> > And the resource is not loaded (even if the integrity is valid).
> >
> > I see that spec says "Integrity metadata delivered over an insecure
> channel
> > provides no security benefit"
> >
> https://w3c.github.io/webappsec/specs/subresourceintegrity/#insecure-channels-remain-insecure-1
> >
> >
> > I don't think that statement is totally accurate. There is still a
> benefit
> > if the sub-resource origin is compromised and the requesting resource is
> > not.
> >
> > Suppose https://jquery.com wanted to put this up on their homepage so
> > developers could just copy and paste:
> >
> > <script src="//code.jquery.com/jquery-1.10.2.min.js"
> >
> >
> integrity="ni:///sha256;C6CB9UYIS9UJeqinPHWTHVqh/E1uhG5Twh+Y5qFQmYg=?ct=application/javascript">
> >
> > Any site that copied the code with the integrity hash will be protected
> if
> > code.jquery.com is compromised.
> >
> > If the current blocking remains, then jquery.com would either not
> include
> > the integrity because it would fail for many developers, or they would
> have
> > to add an explanation that you can only use integrity when your page is
> > loaded over HTTPS and provide two code snippets (potentially confusing).
> >
> > If you allow integrity in documents hosted on insecure origins the number
> > of sites the a CDN attacker can compromise will be reduced significantly.
> >
> > Keep up the great work!
> >
> > --
> > Pete Freitag
> >
>
>