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

Re: Testing W3C's HTTPS setup

From: Mike West <mkwst@google.com>
Date: Mon, 21 Sep 2015 13:27:48 +0200
Message-ID: <CAKXHy=fCQYXtBaLgcMXif40MP9ubhxdUj3K1t3CzBORrPhAAAQ@mail.gmail.com>
To: Jose Kahan <jose.kahan@w3.org>
Cc: Wendy Seltzer <wseltzer@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Mon, Sep 21, 2015 at 1:22 PM, Jose Kahan <jose.kahan@w3.org> wrote:

> As you say, firefox doesn't seem to support this header when the
> server sends it.

In that case, why are you redirecting it to HTTPS and serving the HSTS

> > Wouldn't it be better to fix the absolute HTTP links? That would solve
> the
> > problem for Firefox, and browsers like Safari that don't support the
> > upgrade feature at all.
> That's not possible. We have too much content and this is what
> the combination of HSTS and Upgrade-Insecure-Requests is supposed
> to do.

I do hope that you see `upgrade-insecure-requests` as a transitional phase,
and that you're working to fix the mixed content errors on the site, rather
than relying on browser support in perpetuity.

If there's no other available solution at the moment that fixes
> firefox's behavior, we'll have to roll-back.

I guess it's not clear to me why you're fine with the current setup for
browsers like Safari, but aren't fine with it for Firefox? Wouldn't you
just treat Firefox like every other browser that doesn't support the
upgrade directive? That is:

* If you don't see an `upgrade-insecure-requests` header in the navigation
to `http://w3.org/`, don't redirect to HTTPS.

* If you don't see an `upgrade-insecure-requests` header in a navigation to
`https://w3.org`, downgrade to HTTP (and don't serve HSTS)?

This use case is why we added the signaling header. :)

Received on Monday, 21 September 2015 11:28:35 UTC

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