Re: HSTS Priming, continued.

A nice benefit of the priming approach for HSTS is that you do receive a
durable signal which the browser can cache, and which can prevent downgrade
attacks on subsequent connections.  Also consider that some sites may not
set HSTS for every response, but only for well-known app "entry points" (to
optimize network traffic).  So the things that are relied upon as
subresources may not send the HSTS header, but a priming request to "/" is
very likely to.  So with the simple proposal you might get HTTPS
successfully in the absence of an attacker, but never receive an HSTS
signal, and remain vulnerable to downgrade as soon as an attacker appears.

On Wed, Nov 11, 2015 at 1:07 PM Daniel Kahn Gillmor <dkg@fifthhorseman.net>
wrote:

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