Re: "Subresource Integrity" spec up for review.

-security-dev to BCC
+public-webappsec, Brad Hill

I'm moving this thread to public-webappsec so that folks there can comment
directly.

On Sat, Jan 11, 2014 at 5:03 AM, Ryan Sleevi <rsleevi@chromium.org> wrote:
>
> On Wed, Jan 8, 2014 at 3:29 AM, Mike West <mkwst@chromium.org> wrote:
>
>> Hello, lovely friends of Chromium security!
>>
>> Frederik, Devdatta, Joel, and I have been working with folks in the
>> webappsec WG to put together a specification of the ages-old idea of
>> jamming hashes into an HTML page in order to verify the integrity of
>> resources that page requests. A strawman draft is up at
>> http://w3c.github.io/webappsec/specs/subresourceintegrity/ for review.
>>
>> Given that some of the proposals are interesting from a security
>> perspective (in particular, using hashes as cache identifiers, and
>> potentially relaxing mixed-content checks if the hashes are delivered over
>> HTTPS), it'd be brilliant to get early feedback so we can make sure the
>> spec is sane.
>>
>
> I... have a hard time with this proposal and its use cases beyond the
> first and third.
>

I think you'll find that #2 is really #1 in disguise.


> I apologize that I don't have the bandwidth to jump into the fray and
> really engage in the W3C group right now, but I can hope you can convey the
> message.
>

No worries. I appreciate the feedback, and we'll pick up the conversation
on the W3C list. Please don't feel obligated to keep up with this thread;
feel free to mute it.


> +1 to 1) Site wants to ensure third-party code doesn't change from what
> they reviewed. Cool
>

Good! This is more or less the core of what I want to achieve. Everything
else is nice to have.


> +wtf to 2) Site wants to ensure... code review? How is that an HTML
> problem? How is it reasonable to induce the CPU costs on millions of users
> to enforce what is ultimately a procedural problem at the company? How is
> it in the interest of the users?
>

The use-case was written unclearly. I've rewritten it in the hopes of
making it something you'd agree with.

In short: an advertising network like Doubleclick delegates the actual
delivery of advertising content to third-party servers, and relies on
contractual obligations (and probably automated checks, etc) to ensure that
the advertisement delivered is the advertisement that was reviewed. Those
third-parties sometimes accidentally (or maliciously) deliver altered
content. By adding integrity metadata to the iframe that wraps an ad, and
by requiring the ad HTML to contain integrity metadata for subresources, ad
networks can mitigate this risk.


> +0 to 3) I'd say this is where you use HTTPS, especially in light of
> discussions to 'downgrade' HTTP downloads.
>

1. HTTPS gives different integrity promises: it verifies that the server
you're talking to is the one you're expecting, and gives some protection
against MITM alterations.

2. For the same reason that use-case #1 is valuable, even over HTTPS,
validating download integrity is valuable.


> +? to 4) "altered Javascript from the filesystem" is certainly an
> unrealistic threat that a UA cannot and should not pretend it can defend
> against, unless that UA is running itself in a higher privilege than the
> files its accessing - in which case, it should be storing those files
> securely.
>

Freddy's original proposal was meant to cover browser UI that loads script
off the net directly. This would cover, for example, Chrome's NTP.

I've removed the "filesystem" language, as I agree with your criticism.


>  +wtfbbqomg to 5) We have had this amazing way of expressing versions for
> resources since the introduction of HTTP. It's called the URL. If the
> author wants to express a dependency on a particular version, the amazing
> power of the web allows them to put a version within a URL and depend on
> that.
>

This is probably also poorly worded: I believe the intent was another spin
on #1. If I load a resource from a server, I'd like to ensure that it
hasn't been swapped out behind my back. If it has been swapped out, the
reporting functionality will alert me to the fact, I'll go review the new
code, and either update the integrity metadata, or rework the mashup to use
some other resource if I don't like the changes.


> +awwhellnaw to 6) "performance reasons" is not and has not been a
> realistic problem for properly-configured SSL for some time. The example
> already establishes that the user supports some degree of
> properly-configured SSL at rockin-resources.com, so there's no reason
> *not* to use it.
>

I'm still hopeful that Brad (Hi Brad!) will take some time to give more
detail around the value proposal for mixed content relaxation and the
fallback mechanism. I think several of the editors share your opinion here.


> The only 'performance reasons' I'm aware of are those ever-insidious
> transparent, caching proxies. Yes, they're ubiquitous. But if you're trying
> to solve that problem, you need to come out and say it. "An author wishes
> to load a resource that a person in a privileged position on the network
> would prefer to intercept and redirect."
>

I'll work that in somewhere. I do think creating transparency into that
manipulation is part of the intent, in much the same way that CSP showed
folks like Twitter how much code was being injected into their HTML pages,
integrity verification can make it clear how many resources are changed
in-flight.


> Especially in the nature of our Post-Snowden World, integrity without
> privacy seems to be setting the bar too low.
>

The current suggestion is that any HTTP->HTTPS fallback system would omit
credentials from requests to the HTTP server. I agree that that still opens
some windows into your browsing activity that might be better left closed.


> And integrity with privacy is easily obtained - with HTTPS.
>

I don't think that's the case, at least, not in the sense of verifying that
the resource you're loading hasn't been altered on the server. HTTPS
mitigates the risk of middle-men inbetween you and the server you're
talking to. It does nothing to verify that the server itself hasn't been
compromised.

Thanks again for spending some time on this, Ryan. I appreciate it.

-mike