W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2014

Re: [SRI] To trust or not to trust a CDN

From: Brian Smith <brian@briansmith.org>
Date: Thu, 20 Nov 2014 13:43:37 -0800
Message-ID: <CAFewVt7qMVz8xcQfOL7FUAwGwQ6HreqUxixnDni-3AuWR9tjvg@mail.gmail.com>
To: Brad Hill <hillbrad@fb.com>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, Joel Weinberger <jww@chromium.org>, Hatter Jiang OWS <hatter@openwebsecurity.org>, Ben Toews <btoews@github.com>, Mike West <mkwst@google.com>, Frederik Braun <fbraun@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Nov 19, 2014 at 5:24 PM, Brad Hill <hillbrad@fb.com> wrote:
> The reason for non-canonical-src in a minimum viable product, and for it
> to not check integrity, is the widespread presence of "authorized" proxies
> that modify content, especially script content.  These are deployed at a
> significant number of networks in enterprises, governments and the
> military.

Thanks for explaining that. Why is this a concern for SRI but not CSP
hash-source? Or, if it is a concern for hash-source, then why doesn't
hash-source have a similar mechanism?

> I expect that resource authors might be willing to let the 1-2%
> of users behind such appliances suffer poor performance after SRI
> deployment, in order to increase safety for everyone else.  But I doubt
> they are willing to outright break those users.

Usually it would be 1-2%. But, sometimes it will be 100% of users,
when things go wrong.

> It's the same reason that key-pinning has an "out" for trust roots that
> aren't pre-installed.  That approach seems like a better solution,
> functionally, (disable SRI if you got a valid HTTPS connection chaining to
> a non-pre-installed trust anchor) but I worry that it is a layering
> violation.

It seems really heavyweight to add the noncanonical-src attribute to
every element to provide a fallback, and also do two network fetches
*for every single script*, just to have both copies of the script
modified the same way, such that all the additional fetches were
effectively a complete waste. This makes me think that
noncanonical-src isn't a great solution to the problem of tampering
MitM proxies.

As far as (political) policy is concerned, adding such features to
HTML is ultimately an endorsement of content inspection/tampering
proxies. It seems better to keep the workarounds for them out of HTML
specifications and out of standards in general, except to mention them
as something to consider. See how the HPKP specification handled this
for an example of what I mean.

Like you suggested, I think it makes sense for browsers to offer a
"enable/disable anti-tampering security features for this CA" option
on a per-root-CA basis, and probably default non-built-in CAs to
"disable". Such a setting would be useful for key pinning and other
features besides SRI.

A potentially cleaner mechanism would be a hop-by-hop HTTP response
header that is required for SRI to be enforced for the page. When the
MitM proxy drops the header, then SRI isn't enforced. Then a passive
proxy could add support for SRI by simply recognizing and forwarding
that header. This would (I hope) reduce the problem down to MitM
proxies that tamper with content and also inappropriately handle
hop-by-hop headers (which could be dealt using the per-CA
enable/disable bit I mentioned above).

I think it would be good to try these alternative options first before
settling on adding noncanonical-src.

Received on Thursday, 20 November 2014 21:44:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:43 UTC