W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2015

Re: [UPGRADE]: What's left?

From: Mike West <mkwst@google.com>
Date: Fri, 6 Mar 2015 11:28:56 +0100
Message-ID: <CAKXHy=eH-xwsG-URu=oPxkcOgnuF683ybVOX73S6xM+nanWfew@mail.gmail.com>
To: Yves Lafon <ylafon@w3.org>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Jeff Hodges <Jeff.Hodges@kingsmountain.com>, Tanvi Vyas <tanvi@mozilla.com>, Peter Eckersley <pde@eff.org>, T Guild <ted@w3.org>, Daniel Appelquist <appelquist@gmail.com>, Alex Russell <slightlyoff@google.com>
On Fri, Mar 6, 2015 at 11:10 AM, Yves Lafon <ylafon@w3.org> wrote:

> On Fri, 6 Mar 2015, Mike West wrote:
>
>  I've done some work on the "Upgrade Insecure Requests" spec since the FPWD
>> was published (and have a 90% functional implementation behind a flag in
>> Chrome). I'd appreciate it if folks here would take another look at the
>> document to see if we're converging on something we like:
>> https://w3c.github.io/webappsec/specs/upgrade/
>>
>> The only issue noted in the document is
>> https://github.com/w3c/webappsec/issues/184, which suggests changing
>> from a
>> value-less directive to a whitelist of hosts. I can see how that would be
>> valuable, but it seems like a complicated thing to add if we don't
>> actually
>> need it. Do folks here think it is necessary?
>>
>
> Well, if you are able to select what to upgrade on a fine-grain basis, you
> are not solving the issue, just reducing the surface of attacks (the number
> of insecure links to upgrade), in that case, they can rewrite part of the
> content to that effect. Here the goal was to mass-upgrade things you were
> not able to rewrite, so not worth the complexity of adding it, IMHO.


Alright. That's three votes for "Leave it like it is." Thanks!


> In particular, I'm CCing some W3C folks (Ted and Yves) who participated in
>> an earlier thread[1] to see if this would help them more quickly migrate
>> to
>> HTTPS. Hi! Does this help for the W3C's use-case?
>>
>
> There were a few things, this document addresses the use case of upgrading
> content that are not upgraded by HSTS, which is great!
>

Are there other barriers to migration that this doesn't address?


> I'm wondering about the "insecure content warning" on browers, so would
> this make the warning disappear in implementations (ie: is it linked to the
> enforced policies), but that's more implementation-specific.


Exactly. The intent is to avoid the insecure content warning, and that's
how Chrome's experimental implementation works. Perhaps it's worth adding a
note about that to the document...

-mike

--
Mike West <mkwst@google.com>, @mikewest

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.)
Received on Friday, 6 March 2015 10:29:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:11 UTC