Fwd: subresource integrity and browser extensions

Forwarding this on from Yan Zhu.

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)


---------- Forwarded message ----------
From: Yan Zhu <yan@eff.org>
Date: Tue, Mar 25, 2014 at 10:35 PM
Subject: Fwd: subresource integrity and browser extensions
To: Mike West <mkwst@google.com>


Hi Mike,

Somehow my emails to public-webappsec aren't going through even though
I'm subscribed and getting emails :(. Feel free to forward or I can
continue troubleshooting.

-Yan


-------- Original Message --------
Subject: subresource integrity and browser extensions
Date: Tue, 25 Mar 2014 13:27:10 -0700
From: Yan Zhu <yan@eff.org>
To: public-webappsec@w3.org <public-webappsec@w3.org>

Hi all,

Mike West seemed to suggest on EFF's crypto-ops mailing list thread
about SRI [1] that the spec should address how SRI interacts with
browser extensions. I thought I would cross-post my input as the
maintainer of HTTPS Everywhere (https://eff.org/https-everywhere).

[1] https://lists.eff.org/mailman/listinfo/crypto-ops. Archives are
visible to list members only.


Mike West wrote:
> This proposal _would_, however, make it difficult for extensions to
> redirect one request to another resource. That's something we should
> address in the spec; extensions should be capable of bypassing these
checks.

This is the HTTPS Everywhere problem. It's possible that a resource will
fail SRI checks when it's rewritten (correctly!) by our extension to its
HTTPS version. This rewrite definitely happens before SRI gets a chance
to work because it occurs inside a web request listener.

Here are two examples of things we've seen in the real world:
1. The title of http://site.com is "Welcome to our site!" whereas the
title of https://secure.site.com is "Welcome to our secure site!" The
SSL version gets blocked when it's inside an iframe with a SRI hash for
the non-SSL version.
2. The SSL version of a resource has all of its own subresource URL
schemes changed from "http://" to "https://", because the developer has
some server-side script that detects whether the resource is served over
SSL and changes the URLs accordingly (perhaps for mixed content reasons).

In general, there's no guarantee that a site is serving the exact same
resource over HTTP and HTTPS; part of the job of HTTPS Everywhere
contributors is to check and make sure that any differences are innocuous.

The reasonable solution is to allow extensions to bypass SRI, though
this may cause website operators and extension repository maintainers to
complain that extensions shouldn't have the power to *disable* security
features unless the user installed them for that purpose or had to check
a box giving them permission to. Nonetheless, I think specifying that
extensions can bypass SRI in the spec is a good idea if there are no
objections.

I'm not too concerned either way; we've survived more annoying breakages
in the past.

Hope this is useful,
Yan