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

Re: HSTS Priming, continued.

From: Brian Smith <brian@briansmith.org>
Date: Wed, 11 Nov 2015 09:38:55 -1000
Message-ID: <CAFewVt6DznBJsidf76k=F72Y1zyC=rfxt1Qzpsw4znAoVjdqCw@mail.gmail.com>
To: Crispin Cowan <crispin@microsoft.com>
Cc: Brad Hill <hillbrad@gmail.com>, Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Richard Barnes <rbarnes@mozilla.com>, Jeff Hodges <jeff.hodges@paypal.com>, Anne van Kesteren <annevk@annevk.nl>, Adam Langley <agl@google.com>
Crispin Cowan <crispin@microsoft.com> wrote:

> Dumb/newbie question: wouldn’t HTTPS upgrades be easy if only client
> browsers tried HTTPS *first* for every resource? Then fail back to HTTP
> if policy allows, or block if policy disallows mixed content.

I agree that this sounds better to me. In particular, before doing a
mixed-content subresource load, first try the subresource load over https://.
If the response has the HSTS header then you are golden. Otherwise, if the
response is a 2xx without HSTS (but with the expected content-type--no
sniffing), then it's probably better to just use the HTTPS response anyway;
it might be the wrong response, but it's probably not going to be much
worse than the lack of a response that mixed content blocking causes.
Otherwise, if it is <img>, <video>, <audio>, continue on with the mixed
content load if you feel like it.


Received on Wednesday, 11 November 2015 19:39:27 UTC

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