- From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
- Date: Wed, 11 Nov 2015 16:06:54 -0500
- To: Brian Smith <brian@briansmith.org>, 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>
On Wed 2015-11-11 14:38:55 -0500, Brian Smith wrote:
> 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.
fwiw, i agree with Crispin and Brian that this approach seems simplest
and cleanest.
it also avoids the subtle shift in semantics of the
Strict-Transport-Security header described in
https://mikewest.github.io/hsts-priming/#goals, and doesn't depend on
the subresource's origin having enabled HSTS at all.
The main difference between Crispin's simple proposal and HSTS priming
seems to be for subresource origins that supply different content at
https vs. http URLs and don't set HSTS.
In priming, those particular subresources will be blocked or the http
resource fetched (depending on UA policy). In the simple proposal, for
those particular subresources, the https resource will be fetched; if
that fails, the http resource will be fetched instead.
Do we need to care about this case enough to add the complexity of
priming? or are there other corner cases where the two approaches will
behave differently?
Note that one of the reasons that the subresource origins don't want to
serve an HSTS header is precisely because they are afraid of *other*
consequences (mixed content results) for their own content that they
haven't been able to fix yet. Priming the UA's HSTS cache doesn't
address this concern any better than the simple approach, and the simple
approach should work even with subresource origins that can serve https
but aren't yet confident enough about setting HSTS.
--dkg
Received on Wednesday, 11 November 2015 21:07:48 UTC