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

Re: [SRI] may only be used in documents in secure origins

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Tue, 4 Nov 2014 15:07:43 -0800
Message-ID: <CALx_OUAHmVNKpmrpx52f38Y7TXxrwp19Y_vq_DB=2xgC+fB8VA@mail.gmail.com>
To: Tanvi Vyas <tanvi@mozilla.com>
Cc: Chris Palmer <palmer@google.com>, Joel Weinberger <jww@chromium.org>, Frederik Braun <fbraun@mozilla.com>, Pete Freitag <pete@foundeo.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
For what it's worth, for all the attention that HTTPS is getting of
recent (for good reasons), I suspect that an opportunistic compromise
of a JS-hosting CDN is a more endemic and pervasive risk to most users
than the possibility of active MITM on unencrypted wifi or so.

While I'm strongly in support of pushing high-profile sites over to
HTTPS (*koff* Amazon *koff*)... unless we're completely writing HTTP
off, it's probably reasonable to allow the "bad CDN" problem to be
addressed by SRI independently of deploying HTTPS everywhere.


On Tue, Nov 4, 2014 at 2:41 PM, Tanvi Vyas <tanvi@mozilla.com> wrote:
> SRI on an non-secure origin does not protect the user from an active network
> attacker that is MITM'ing their connections and changing their content.  But
> SRI on a non-secure origin does protect the user who is not subject to an
> active attack and who is trying to source javascript from a third party that
> has been compromised.  For me, that's a good enough reason to allow SRI on
> non-secure origins.
> Most users aren't going to understand SRI at all and it's not a user facing
> feature, so we aren't giving them any new or misleading security guarantees.
> There may be other new features that we want to restrict to HTTPS as a stick
> to get developers to migrate to secure origins, but features like SRI that
> can only help protect users shouldn't be put in that bucket.
> On 11/3/14 4:28 PM, Chris Palmer wrote:
>> On Mon, Nov 3, 2014 at 4:02 PM, Joel Weinberger <jww@chromium.org> wrote:
>>>> Although it would be desirable for every site to use HTTPS,
>>>> I don't think that SRI is the right way of promoting this.
>>> This isn't a matter of promoting HTTPS; it's a matter of suggesting to
>>> users
>>> and developers that they're getting a security property that they're
>>> simply
>>> not getting.
>> Exactly.
>> I'm increasingly concerned about this idea, popping up in several
>> contexts now, that there can be any security at all without at least
>> strong server authentication, data integrity, and data
>> confidentiality. Like, we need those as the baseline minimum, so that
>> we can *begin* to think about the next problems, like metadata
>> confidentiality.
>> Putzing around in the margins like this (Better Than Nothingism) is
>> not going to help users.
Received on Tuesday, 4 November 2014 23:08:30 UTC

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