Require that proxies do not modify integrity checked assets

[ScottHelme]

I recently found a bug in Chrome on Android where the Data Saver feature compresses scripts and other assets that results in the SRI check failing.

On a device browsing a HTTP page that contains HTTP assets this can result in a completely broken browsing experience for the user with no indication of what caused the problem and is quite difficult for the site owner to debug.

Could we require that any proxy or device along the transport layer not modify assets that are integrity checked to allow the SRI mechanism to work as intended without unnecessary breakage?

This would apply to a HTTP proxy like Data Saver or even a HTTPS intercepting proxy.

@mikewest outlined 3 proposals in the Chromium bug.

1. Do not modify integrity-checked assets (e.g. <script integrity="..."> and <style integrity="...">.

2. Modify the integrity metadata of the page to match the result of the data-saving modifications.

3. Remove the integrity attribute from munged script.

I'm a fan of 1 because this would still protect us against a rogue CDN or CDN compromise, or, any alteration that took place upstream of the proxy. 2 and 3 seem to introduce more risk than is necessary by masking any problems prior to the proxy interfering.

@marumari raised some valid points on the Chromium bug too.

Chrome Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=642928

[shekyan]

I would propose the 4th one: do not enforce SRI on non-secure origins.

[ScottHelme]

@shekyan yes, there is that, but don't we lose the protection offered if the CDN changes the asset?

[shekyan]

We do, but with insecure transport main document can be modified to remove integrity metadata anyway.

[ScottHelme]

So because it doesn't offer perfect protection we should revert to no protection?

[shekyan]

Something to consider:) Just an option to review. In my opinion, doesn't offer perfect protection == no protection.

[fmarier]

The spec already talks about these kinds of proxies: https://www.w3.org/TR/SRI/#proxies

[ScottHelme]

You know it's been a long day when you miss that...

[mozfreddyb]

The Cache-Control header can be sent in both requests and responses. The proxy section only mentions this for server responses.

Maybe SRI should make browsers request the resource to be no-transformed? WDYT?

[fmarier]

The Cache-Control header can be sent in both requests and responses. The proxy section only mentions this for server responses.

Maybe SRI should make browsers request the resource to be no-transformed? WDYT?

In w3c/webappsec#217 (comment) (and w3c/webappsec#217 (comment)), mnot pointed out that this doesn't do what it sounds like it should do.

[mozfreddyb]

OK, so we've learned that no-transformis only useful for the request.
Can the user agent ask the server (and proxies) to never transform the response?

I think the problem @ScottHelme is a legitimate problem, but it's maybe a problem the "Data Saver" proxy wants to solve, not the Chrome browser (hence it was wontfixed).

I consider closing this issue. It has been quiet for more than 2 years and I'm unsure whether there's actually a way for the user agent to ask.

[annevk]

I think you still need to update the incorrect advice in https://w3c.github.io/webappsec-subresource-integrity/#proxies before closing this, no? I agree that we don't really want to change anything here implementation-wise.