Re: HSTS, mixed content, and priming

On Tue, Aug 25, 2015 at 12:10 PM, Anne van Kesteren <annevk@annevk.nl>
wrote:

> On Tue, Aug 25, 2015 at 5:02 PM, Richard Barnes <rbarnes@mozilla.com>
> wrote:
> > On Tue, Aug 25, 2015 at 2:24 AM, Brian Smith <brian@briansmith.org>
> wrote:
> >> Why not send a GET request to https://example.com/foo/bar.js as though
> it
> >> was already upgraded via HSTS, and then use the response if the response
> >> includes an HSTS header? This would save one request/response and would
> >> avoid the practical problems with using HEAD. (Although servers are
> supposed
> >> to return the same headers for HEAD requests that they return for GET
> >> requests, in practice many do not.)
> >
> > I think the worry here is leakage -- if the HTTPS site is actually
> > different, then you're leaking request context in the GET.
>
> So given a site A that accesses a site B that has an HTTPS site on the
> same domain B'. The worry is that we're leaking to B' that the user is
> visiting A, while only B (and all network attackers which we assume B'
> is not part of) should know that?
>
> Given that deprecating HTTP is a thing I think that should be acceptable.
>

I could probably live with the privacy risk, but we we might want to keep
priming in mind in case other folks think this is a big deal.

Serving the HSTS header on the resource itself makes me wonder if there are
deployment issues lurking here.  The site operator has to send the HSTS
header on every request, instead of just for the resource the priming query
hits.

I also note that this puts HTTP at a latency disadvantage even when it will
work, which seems like a feature.

--Richard



>
>
> --
> https://annevankesteren.nl/
>