Re: Upgrade mixed content URLs through HTTP header

On Tue, Feb 3, 2015 at 8:40 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Mon, Feb 2, 2015 at 7:53 PM, Daniel Kahn Gillmor
> <dkg@fifthhorseman.net> wrote:
> > 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?
>
> We have already decided that a resource on example.com (with HSTS)
> that has a subresource <img src=http://example.com/img> will result in
> a mixed content warning.


This actually seems meaningfully different from the way we've phrased the
question before. If we began interpreting strict transport security as
rewriting all URLs on a page, we'd avoid some of the questions around
request-order-specific behavior.

In MIX, we currently point to some of this in
https://w3c.github.io/webappsec/specs/mixedcontent/#further-action. I'd
been thinking about STS as a signal to enable strict-mode (e.g. don't even
attempt to load any insecure resource), but optimistically rewriting
resource URLs (and hard-failing if they fail to load) is an interesting
approach.

On Tue, Feb 3, 2015 at 1:42 AM, Peter Eckersley <pde@eff.org> wrote:

> > That said, I'm not sure it actually solves W3C's concern, as it would
> leave
> > legacy clients out in the cold. The only way to support clients that
> don't
> > support the thing we haven't implemented yet would be to alter the links
> at
> > the source. I totally understand that that's difficult, but it seems
> > essential.
>
> It seems like you're saying that a security mechanism can't be allowed
> to help new clients upgrade to HTTPS if it doesn't also help old ones?
>

That's not what I mean to say. With regard to the W3C, my (apocryphal?*)
understanding is that the main blocker to deploying HTTPS more widely is
legacy clients, not legacy content, and that they'd need to alter the
source in order to get over that hurdle. The legacy concern was specific to
this example, not a general statement on adding features to the platform.

*Wendy (hi!) could probably comment here.

--
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.)