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

Re: Upgrade mixed content URLs through HTTP header

From: Ryan Sleevi <sleevi@google.com>
Date: Tue, 3 Feb 2015 01:47:10 -0800
Message-ID: <CACvaWvb_faBNbjD6ZgvkL=+dy1Uh4_udEu1D0XN+NfsHT=JxTA@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: "Eduardo' Vela" <evn@google.com>, Anne van Kesteren <annevk@annevk.nl>, Wendy Seltzer <wseltzer@w3.org>, Adam Langley <agl@google.com>, WebAppSec WG <public-webappsec@w3.org>, Peter Eckersley <pde@eff.org>
On Feb 3, 2015 1:41 AM, "Mike West" <mkwst@google.com> wrote:
> On Tue, Feb 3, 2015 at 10:21 AM, Anne van Kesteren <annevk@annevk.nl>
>> On Tue, Feb 3, 2015 at 10:18 AM, Eduardo' Vela" <Nava> <evn@google.com>
>> > Would this enable the upgrade only? Without the STSing?
>> >
>> > Strict-Transport-Security: max-age=0; upgradeSubresources
>> I think Mike was suggesting not to extend HSTS but instead use the
>> presence of HSTS as a signal to upgrade all mixed content URLs within
>> the document. It's not entirely clear to me if that is compatible with
>> what is out there today. And if coupling it with HSTS helps adoption
>> or makes it harder.
> Right. All good questions.
> My intuition is that if a site is already setting HSTS, and includes
insecure resources, then they're already living with brokenness. Breaking
them in a different way (by failing to load HTTPS resources) doesn't seem
substantially worse (though might have negative performance impacts,
assuming a failed connection takes some amount of time to timeout).

I'm not sure I follow this, so apologies for not fully keeping up with the
shifting thread. When extended to third-party resources, if I embed an HTTP
image from a third-party origin on a site with HSTS, it will load but
degrade UI. If I auto-upgrade that other origin to HTTPS, it will fail to
load - that does seem considerably worse, doesn't it?

I suppose it presumes using HSTS as a signal for hard mixed-content
blocking, which I realize has been suggested before, but not presently

> Using HSTS as a signal almost certainly doesn't solve the adoption
problem; no one is sending the HSTS header unless they've already done
substantial work to get ready. This would simply be a mechanism of ensuring
that the effort was well-spent, and had the desired effect.
> --
> 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
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Tuesday, 3 February 2015 09:47:38 UTC

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