HSTS Priming

Hi public-webappsec!

Preliminary support for HSTS Priming is in review and should land soon on
Firefox Nightly. Due to the complexity of the load sequence and
interactions with caches and so on, as well as dependencies of many tests
on the current behavior, it took a bit longer than expected.

HSTS Priming is enabled through two preferences,
security.mixed_content.send_hsts_priming and
security.mixed_content.use_hsts. When
security.mixed_content.send_hsts_priming controls is set to true, the
browser is may send an HSTS priming request. If
security.mixed_content.use_hsts is true, HSTS upgrades will be applied
before mixed-content blocking, if set to false, it preserves the current
blocking behavior. The security.mixed_content.send_hsts_priming will ride
the trains, and security.mixed_content.use_hsts will be enabled in Nightly,
Aurora, and Beta, but disabled in Release until more browsers implement it.

HSTS Priming adds an assertion that we have seen a site and not received
the HSTS priming flag. This is only used for determining whether to send a
new priming request, and an be overridden if an HSTS header is detected.

There are three related histograms, two of which will begin collecting data
after the patch lands (there is one already in the code).

MIXED_CONTENT_HSTS - (exists) whether or not HSTS would succeed in a
mixed-content load.
MIXED_CONTENT_HSTS_PRIMING - same as MIXED_CONTENT_HSTS, but adds whether
or not a priming request would be sent.
MIXED_CONTENT_HSTS_PRIMING_RESULT - the outcome of sending a priming
result, including the effect of preferences on the load.

https://bugzilla.mozilla.org/show_bug.cgi?id=1246540 tracks the
proof-of-concept, and https://bugzilla.mozilla.org/show_bug.cgi?id=1246537
tracks the remaining work.

Thanks,
~Kate

--
Kate McKinley
kmckinley@mozilla.com