1246537 - [META] HSTS priming

Status: RESOLVED WONTFIX

(Core :: DOM: Security, defect)

Description

[Kate McKinley [:kmckinley, :Kate]]

Mixed-content blocking may prevent some sites from moving from HTTP to HTTPS. In order to help sites opportunistically move to HTTPS, we introduce the concept of HSTS Priming.

In the case where the browser is on a secure page and would attempt to load an a-priori non-secure URI, the browser will send a priming request via HTTPS to the host. If successful, and the response contains the Strict-Transport header, the contents of that header will be cached and the load will proceed with the secure origin.

This will eventually require changes to several specs, notably FETCH, MIXED-CONTENT, and HSTS.

References:
https://mikewest.github.io/hsts-priming/
http://webappsec-test.info/~bhill2/DifferentTakeOnOE.html

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

How do we expect this to work with service worker interception?  Should the priming request bypass the service worker or be interceptable via the fetch event?

Comment 3

[Richard Barnes [:rbarnes]]

(In reply to Ben Kelly [:bkelly] from comment #1)
> How do we expect this to work with service worker interception?  Should the
> priming request bypass the service worker or be interceptable via the fetch
> event?

That's a good question.  Shouldn't we just generally treat SW-intercepted requests as if they're secure?  After all, they didn't even leave the browser.  Probably a good question for the Secure Contexts spec.

Comment 4

[Christoph Kerschbaumer [:ckerschb]]

HSTS Priming was removed from the codebase within Bug 1424917 which renders this META bug as WONTFIX.