On Wed, Nov 11, 2015 at 3:35 PM, Brian Smith <brian@briansmith.org> wrote:
> On Wed, Nov 11, 2015 at 11:30 AM, Brad Hill <hillbrad@gmail.com> wrote:
>
>> A nice benefit of the priming approach for HSTS is that you do receive a
>> durable signal which the browser can cache,
>>
>
> HSTS is cached for the entire origin, regardless of which resource it
> comes from.
>
Brad's saying that the HSTS header is more likely to be present at "/" than
at the URI of the resource being fetched.
>
>
>> and which can prevent downgrade attacks on subsequent connections.
>>
>
> This is the same in both approaches.
>
See above.
>
>
>> Also consider that some sites may not set HSTS for every response, but
>> only for well-known app "entry points" (to optimize network traffic).
>>
>
> Does this still matter, performance-wise, for HTTP/2 connections, given
> header compression? Just send the HSTS header for all resources for HTTP/2
> connections and rely on compression to work. Browsers that would support
> HSTS priming also support HTTP/2 and HTTP/2 header compression.
>
> Conversely, consider a server that never expects a request to "/" and so
> never sets the HSTS header field (e.g. because it forgot to put the HSTS
> header field on its error responses, which is a very common failure mode).
>
Well, for one, we could use browser telemetry data (maybe) to measure
whether Brad is right or you are right about whether HSTS is more likely on
the root or the resource.
But for another: introducing HSTS priming is itself likely to change
behavior, by providing a very powerful incentive for CDNs and other
resource hosts to add an HSTS header.
Today, adding HSTS to an asset host really only upgrades existing links
that have been placed on HTTP websites. HTTPS websites won't get their
links upgraded because it gets blocked as mixed content first, and so asset
hosts are unable to make the transition easier for websites that put in
legacy HTTP links no matter what they do.
With HSTS priming, an asset host opts in by adding an HSTS header to "/",
and responding to HEAD requests. With opportunistic HTTPS, an asset hosts
has to make sure an HSTS header is present on every resource. The former
sounds much simpler to execute, and will potentially need fewer parties to
coordinate on deployment, than the latter.
Also, consider that many servers don't implement HEAD correctly.
>
While headers and servers can be managed by separate entities, I strongly
suspect that servers/services which don't implement HEAD correctly are
unlikely to have HSTS headers set at all, or likely to set them after HSTS
priming or a more simple prefetch mode is supported.
>
> Cheers,
> Brian
> --
> https://briansmith.org/
>
>
--
konklone.com | @konklone <https://twitter.com/konklone>