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

Re: Upgrade mixed content URLs through HTTP header

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Mon, 02 Feb 2015 13:53:10 -0500
To: WebAppSec WG <public-webappsec@w3.org>
Message-ID: <87386of8mh.fsf@alice.fifthhorseman.net>
On Mon 2015-02-02 10:24:41 -0500, Anne van Kesteren wrote:
> Some members of the W3C staff raised this issue the most clearly,
> though I also found out myself while rolling out TLS on whatwg.org and
> various other domains.
>
> When you have lots of legacy pages that all have various subresources,
> upgrading them all to avoid mixed content warnings (or worse,
> failures) can be a pain. You have enabled TLS for the domains your
> subresources come from, but you don't have the possibility of
> upgrading all the links.
>
> For that scenario it would be useful if we had a header that was
> similar to HSTS, but instead applied to the subresources of the
> current document. HSTS does not help as it a) applies only to a single
> host and any cached hosts and b) happens after mixed content per
> recent agreement.
>
> So I think if we introduced an HTTP response header (only takes affect
> if delivered over TLS) like
>
>   TLS-Only: true
>
> we would enable resources such as
>
>   <!doctype html>
>   <title>Hey!</title>
>   <h1><img src=http://elsewhere.example/test alt=Testing></h1>
>   <script src=http://anywhere.example/run></script>
>
> to avoid mixed content warnings without content changes.

I'll ask the obvious question explicitly:

Why does this need to be a separate header at all?  Why not just assume
that sites with STS set should opportunistically upgrade http resources
to https?

I understand that there are some small minority of sites like
https://forbes.com/ that are radically different from
http://forbes.com/, but the sense i got from the community here in
general is that serving different content on the http and https URLs is
a Bad Idea, and people who choose to do that might just fail.

Given that the operators of the origin server who send STS are going to
ensure that they don't do this Bad Idea, and that they don't actually
have any control over external sites that might do this Bad Idea, having
a separate header to proclaim "we think everyone we pull resources from
is serving the same content on https" doesn't seem like much of a win.

(if i'm pulling an image or a script from http://forbes.com/ in my site
that's covered by STS, it'll fail to load the image either way)

Sites that serve an STS header with mixed content already give their
users a degraded experience.  Why not just improve that optimistically,
instead of requiring yet another header?

        --dkg
Received on Monday, 2 February 2015 18:53:40 UTC

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