W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2016

Re: HSTS priming vs preloading

From: Mike West <mkwst@google.com>
Date: Tue, 2 Feb 2016 15:02:38 +0100
Message-ID: <CAKXHy=d5E1s3USOdyBDmZb1yZDA_0VK=sOxYbss-wKQRyfRKkA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Richard Barnes <rbarnes@mozilla.com>, Eric Mill <eric@konklone.com>, Ben Wilson <ben.wilson@digicert.com>, Jim Manico <jim.manico@owasp.org>, Jim Manico <jim@manicode.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, Feb 2, 2016 at 2:54 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Tue, Feb 2, 2016 at 2:41 PM, Richard Barnes <rbarnes@mozilla.com>
> wrote:
> > That's part of why priming is nice -- it gives you the determinism of
> > preloading, while letting you trade an RTT for not preloading.
> Yeah. The main problem with priming is that it gives an attacker a
> chance so it's not a complete alternative and less than ideal when you
> consider navigations as well rather than just mixed content. (It's a
> step up from where we are today, for sure.) And an alternative where a
> browser hosts the preload table would give the browser insight where
> the user is going (and perhaps slow things down unacceptably). Meh.

You could certainly imagine a world where we'd apply the same concept to
navigation. I don't think we're there yet in terms of the user impact, but
it's certainly feasible. Clever browser folks could even integrate such a
check into their prerendering/preloading logic to try to hide the RTT to
the extent possible.

Even in that world, though, an active attacker can intercede by blocking
the TLS connection entirely. I don't have a good suggestion for avoiding
that risk other than preloading.

Received on Tuesday, 2 February 2016 14:03:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:54 UTC