Re: Subresource Integrity strawman.

On Wed, Jan 8, 2014 at 1:47 PM, Ilya Grigorik <igrigorik@google.com> wrote:

> On Wed, Jan 8, 2014 at 12:07 PM, Joel Weinberger <jww@chromium.org> wrote:
>
>> On Wed, Jan 8, 2014 at 10:52 AM, Ilya Grigorik <igrigorik@google.com>wrote:
>>
>>> Hey all. First off, I wouldn't qualify myself as a "security" person, so
>>> pardon my ignorance... A few high-level questions:
>>>
>>> Authors must trust that the resource their content delivery network
>>>> delivers is in fact the same resource they expect. If an attacker can trick
>>>> a user into downloading content from a different server (via DNS
>>>> poisioning, or other such means), the author has no recourse. Likewise, an
>>>> attacker who can replace the file on the CDN server has the ability to
>>>> inject arbitrary content.
>>>
>>>
>>> Isn't this redundant with HTTPS + HSTS? MITM aside, the transport layer
>>> guarantees data integrity and (pinned) authentication. In light of that,
>>> does this spec provide anything extra? It seems like it would be much
>>> simpler to simply recommend using HTTPS + HSTS.
>>>
>> It is certainly the case that, from a security perspective, using HTTPS +
>> HSTS is better. However, this proposal is meant to address the reality that
>> a lot of content is not being served over HTTPS, and doesn't appear likely
>> to in the near future. For example, many CDNs, for a variety of reasons,
>> serve content only over HTTP. Given this, we still want a way to provide
>> for the integrity of the content that reaches the user agent.
>>
>> Additionally, even if your site is over HTTPS, if you don't have control
>> over the server that serves up some resource you rely on, it may be out of
>> your control that it's over HTTP, but you still want to provide integrity.
>> This allows you to do that.
>>
>
> We want to encourage mixed-content? That seems exactly backwards to the
> goal of this group. Most browsers block mixed content, and ones that
> don't... should.
>
Sorry, I don't mean to imply that we want to encourage mixed content. My
next comment about discouraging developers from moving to HTTPS (which does
not include mixed-content) was meant to point out that I think that's an
issue we need to grapple with here.

In addition, we live in a world with mixed content, so the question is, can
we make users more safe when they go to a mixed content site? That's part
of the goal of this proposal. So there's definitely a balance to strike:
encourage developers to go to full (non-mixed content) HTTPS, but improve
the security of current users as well.

>
>
>> This does bring up the legitimate fear of *discouraging* developers from
>> moving to HTTPS. "Why should I use HTTPS when I can just specify
>> integrities?" I think this is a real concern, and personally, I want to
>> make sure that we're providing other incentives for developers to move to
>> HTTPS. But at the same time, we really owe it to users to make the Web as
>> safe as possible right now, too.
>>
>
> There is a lot of (recent) discussion on http-wg on how to deploy HTTP/2 +
> TLS and various approaches to lower barriers to TLS adoption. FWIW, instead
> of trying to graft integrity onto HTTP, I'd rather see focus on encouraging
> developers adopt HTTP/2 + TLS + HSTS. Speaking of incentives, combining
> performance + better security story is a clear win.
>
I don't believe this is a "choose one or the other" situation. I think we
would all be much happier in an all-TLS world, so we should work on making
that happen. We should also provide lower-barrier tools, where possible,
that increase the security of users.

This isn't just about security, though. Part of the goal, at least for now,
is to improve caching as well. So even if we live in an all HTTPS world,
which provides integrity, there's still no way a priori to identify what
resource you are attempting to load. The integrity attribute is still
useful as a hint about the content you're requesting as well.

>
>

>
>>  Provide authors with a mechanism of reducing the ambient authority of a
>>>> host (e.g. a content delivery network, or a social network that provides
>>>> widgets) from whom they wish to include JavaScript. Authors should be able
>>>> to grant authority to load a script, not any script, and compromise of the
>>>> third-party service should not automatically mean compromise of every site
>>>> which includes its scripts.
>>>
>>>
>>> Ok, to answer my own question: the extra bit of security is that you're
>>> effectively freezing a hash and if your pinned host is compromised and file
>>> is replaced, then UA will bail on execution - right? At which point, if you
>>> absolutely must have control over the target script, why not just freeze it
>>> on a local server? Some sites do that exactly that when deploying third
>>> party widgets / analytics / etc... some for security reasons, others for
>>> performance.
>>>
>>> Further, it seems like in practice the proposed example wouldn't
>>> actually fly:
>>> *<script src="https://analytics-r-us.com/include.js
>>> <https://analytics-r-us.com/include.js>"*
>>> *        integrity="ni:///sha-256;SDfwewFAE...wefjijfE"></script>*
>>>
>>> The whole point of providing a generic "ga.js" or "include.js" is that
>>> it can be revved by a third party - e.g. updates and security fix
>>> deploys... If I add an integrity tag on these resources, I effectively
>>> guarantee that my site is broken next time analytics-r-us.com revs
>>> their JavaScript. Once again, it seems like if you must have this control,
>>> you're better off freezing a local copy on your server, auditing it, and
>>> being responsible for updating it manually.
>>>
>> I view this as a feature. Developers should be aware of the content that
>> they are loading, even if it's from a third-party. But if this problem does
>> arise, the temporary solution is in the "fallback" portion of the proposal,
>> which is still very much up in the air.
>>
>
> Fallback to what? An old copy? What if its purged from cache? ... My point
> is, this proposal doesn't work for majority of cases (3rd party widgets),
> specifically because the resources served by those providers *do change*
> and often quiet frequently. If that's an issue for you, then freeze it on a
> local server.
>
That's a fair point, and it makes it doubtful that you'd use integrity for
those types of widgets. But there are plenty of instances of loading
content from CDNs, images from a third-party site, or other content that
the developer simply wants to ensure is a specific type of content. I'm not
sure about the "majority of cases" claim, though. This is probably
something we can measure, and we probably should.

>
> ig
>