Exempt HSTS-upgraded resources from mixed content blocking

[bifurcation]

The overall goal of this issue is to have HSTS upgrades taken into account at the same level as upgrades via upgrade-insecure-requests, in particular, so URLs that are upgraded through HSTS would not be blocked by mixed content blocking or CSP. There's an easy part and a hard part to this.

The easy part is reversing HSTS and MCB/CSP. I think all that needs to be done for this is to update the main fetch algorithm to take the HSTS upgrade step (#6) and put it immediately after the upgrade-insecure-requests step (#3). That seems like it will prevent HSTS-upgraded loads from getting blocked as insecure.

However, because HSTS information is discovered through browsing, this leads to an unfortunate indeterminism -- the web developer doesn't know whether a visitor to his site will have all the HSTS information necessary to resolve MCB issues.

The hard part is resolving this indeterminacy. In order to do that, ISTM that the right answer is to actively probe for HSTS, i.e., prime the HSTS cache. (Aside: You could do this HSTS probing more broadly, but it's especially important here.) I think the important thing to change here is the following:

If should fetching request be blocked as mixed content or should fetching request be blocked by Content Security Policy returns blocked, set response to a network error. [MIX] [CSP]

• Define an "HSTS priming fetch".
  • This should send a request to the root of a URL of some innocuous method (HEAD?), without credentials.
  • Depending on whether there's an HSTS header in the response, the host should be marked as a Known HSTS Host or a Known Non-HSTS Host.
  • The "Known Non-HSTS Host" status is new. The UA must cache this state for the duration of the main fetch, and may cache it for longer to avoid future priming fetches.
• Update the negative CSP/MCB branch ("If should fetching request be blocked as mixed content or should fetching request be blocked by Content Security Policy returns blocked, set response to a network error. [MIX] [CSP]"):
  • If the host is a Known Non-HSTS Host, return a network error
  • Otherwise, perform an HSTS priming fetch and re-try the fetch

[annevk]

@mikewest does "blocked" checking have reporting side effects?

@bifurcation do we really only want to do this for mixed content that would be blocked? Trying to avoid mixed content warnings altogether would be good, no?

[mikewest]

@bifurcation: Are you working with @rlbmoz on this? This is super-similar to the priming that he proposed (and that I've started writing up at http://mikewest.github.io/hsts-priming/ so I can shop it around to folks who have expressed concerns in the past). :)

@annevk: No, blocking mixed content doesn't have special side-effects. I do need to split CSP into a "report-only" and "enforce" step, however, as we want the former to trigger before upgrading, and the latter after.

Relatedly, I agree that we would want to do this for all non-navigational requests coming from a client that restricts mixed content. I don't think we'd want to do it just for blockable content types, as that would still lead to loading insecure content in some cases where we could otherwise avoid it.

[annevk]

@mikewest ah, you already started working on this, great! I thought the plan was that I would put it in Fetch, but I'm happy for you to drive this too.

My plan was to branch on credentials based on the request since it would allow for reuse of the connection and does not seem dangerous for /. The other bits seem reasonable.

(At some point we should also start doing this for navigational requests, so sites that use HSTS don't have to use HSTS preload to be secure even on first use. But that would be a later addition.)

[mikewest]

For clarity: I want this in Fetch. I don't think I have time to drive it. The document I've started is just an explainer that I can point people to who aren't familiar with Fetch.

For credentials: don't we already need a new connection to move from port 80 to port 443? Or am I missing your concern?

For navigation: see http://mikewest.github.io/hsts-priming/#open-questions. I'm not sure there's any real value in doing so, since it doesn't actually close the initial window of attack.

[annevk]

The concern is that once you do a HSTS preflight using HTTPS that is successful, it would be sad to have to create a new connection for the actual request over HTTPS. So it would be nice to either use credentials for both or neither, depending on the characteristics of the actual request.

(Interesting point about blocking port 443 and that defeating the navigation use case, hadn't thought of that.)

[annevk]

What's the status here? @jonathanKingston we ended up dropping this from Firefox, right?