Re: HSTS Priming, continued.

On Wed, Nov 11, 2015 at 3:06 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.
>

Though the spec describes it as a shift in the assertion, I don't think it
actually is. HSTS has always been a hostname-wide assertion, and I don't
see any practical or philosophical difference between "This host is only
available via secure transport" and "Any resource on this host addressed by
an insecure scheme is available via secure transport".


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

I don't find this very convincing. You're describing a transitory
situation, where a subresource host hasn't added HSTS because it also
serves web content at the same hostname, and hasn't been able to fix their
own mixed content issues.

I say that it's transitory because if subresource hosts that would be
otherwise motivated to add an HSTS header aren't able to fix their mixed
content issues, the problem is likely that there's no HTTPS endpoint
available for whatever mixed content they happen to use. Making third-party
resources available over HTTPS at all is a problem that I think is being
tackled well, even in traditionally stubborn industries like advertising.

By contrast, the situation that HSTS priming is addressing is a problem
that isn't transitory -- how to easily upgrade legacy content that has
insecure references that a simple sed command or template change won't fix.

This spec's goal isn't to find a quick patch to ratchet up the % of HTTPS
requests at the margins for resources which happen to be available over
both HTTP and HTTPS transports. The spec's goal is to describe a formal
path for a sea change in "mixed content reform".

So it's okay to make HSTS priming an "opt-in" thing, because people only
have to opt-in to HSTS -- something that they have existing incentives to
opt-in to, and through HSTS priming, they only have to worry about doing it
on the root of their domain.

-- Eric


>
>        --dkg
>
>


-- 
konklone.com | @konklone <https://twitter.com/konklone>