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

Re: Upgrade mixed content URLs through HTTP header

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 3 Feb 2015 11:50:39 +0100
Message-ID: <CADnb78gDGCCu950gFL5dA8ZeAuo9+66dNx4RqWhxqy=GNOcMAw@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Ryan Sleevi <sleevi@google.com>, "Eduardo' Vela" <evn@google.com>, Wendy Seltzer <wseltzer@w3.org>, Adam Langley <agl@google.com>, WebAppSec WG <public-webappsec@w3.org>, Peter Eckersley <pde@eff.org>
On Tue, Feb 3, 2015 at 11:16 AM, Mike West <mkwst@google.com> wrote:
> Let's say we introduce Eduardo's "upgrade-unsafe". What would you expect it
> to do?
> I'd expect it to blindly rewrite first- and third-party HTTP images (and
> etc.) to HTTPS before fetching, which would simply fail for images
> unavailable over HTTPS. It's not clear to me that that's really worse than
> the browser telling the user that the page is insecure, and it seems like
> different site authors would react differently.

This is what I would expect. And from experience with deploying TLS on
whatwg.org and html5.org I know that we had made sure that the thirty
or so domains for in use (for both primary and subresources) supported
TLS. It was just an enormous hassle to make sure that the content also
matched that. If we had a header to upgrade the content deployment of
TLS would have gone a lot smoother.

> An alternative would be to rewrite first-party requests only. Would that
> address enough of the problem to be worth offering?

No, often you have e.g. resources.domain.example or
potentiallyinsecuresubresources.example to avoid cookies in requests,
as a simple means of load balancing, or simply because it makes it
easier to manage resources in that way.

Received on Tuesday, 3 February 2015 10:51:04 UTC

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