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

Re: Testing W3C's HTTPS setup

From: Jose Kahan <jose.kahan@w3.org>
Date: Mon, 21 Sep 2015 13:48:59 +0200
To: Mike West <mkwst@google.com>
Cc: Wendy Seltzer <wseltzer@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <20150921114859.GA8479@kiribati.inrialpes.fr>
On Mon, Sep 21, 2015 at 01:27:48PM +0200, Mike West wrote:
> >
> > 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.

We need a solution that will allow to assume all content is https,
in perpetuity, without needing to upgrade all legacy content. 
We cannot do a systematic redirection from HTTP to HTTPS for the moment.

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

That's how we set it up.

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

That doesn't make sense. When browsing protected resources, you need
HTTP, you cannot downgrade it to HTTP systematically. What I think
you mean to say is that for public resources, apply the rule you said.
I may be missing some of the context in your statement.

Received on Monday, 21 September 2015 11:49:10 UTC

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