HTTPS Upgrade

[dadrian]

Introduction

Browsers may still make insecure HTTP requests to HTTPS-enabled sites, unless site operators have performed a series of elaborate configuration steps culminating in adding their site to the HSTS preload list. This can happen when the user follows an HTTP link to, or loads an HTTP resource from:

• a site that uses HSTS that the browser has not visited before,
• a site that redirects HTTP to HTTPS (defaults to HTTPS) but does not use HSTS,
• or a site that supports both HTTPS and HTTP and does not redirect HTTP to HTTPS.

In all of these cases, users make insecure HTTP connections to sites that support HTTPS, needlessly compromising their privacy and security. Depending on configuration, a browser could initiate anywhere between one and all of its requests to that site over insecure HTTP.

The idea is that browsers should automatically and optimistically upgrade all in-page HTTP links to HTTPS, with fast fallback to HTTP.

Read the complete Explainer.

Feedback (Choose One)

I welcome feedback in this thread, but encourage you to file bugs against the Explainer.

[ericlaw1979]

Step 5 of Main fetch currently upgrades requests based on the upgrade-insecure-requests mechanism. This will be replaced to upgrade navigation requests (and possibly subresources) regardless of the upgrade-insecure-requests mechanism.

Should we explicitly call out the fact that if upgrade-insecure-requests is specified we are unwilling to fall back to HTTP on error like we will if the CSP directive wasn't specified?

[mikewest]

Should we explicitly call out the fact that if upgrade-insecure-requests is specified we are unwilling to fall back to HTTP on error like we will if the CSP directive wasn't specified?

This seems pretty reasonable to me, though if that ends up being the only thing UIR does (I think the only other delta is upgrading scripts and stylesheets?) it might be reasonable to simply discard it from the platform as a thing that did its job.

[estark37]

Yeah, the existence of UIR continues to get more and more awkward... I would say that for this spec we should continue to preserve UIR's functionality (as @ericlaw1979 suggests), and measure usage/plot its demise as a separate undertaking.

[mikewest]

cc @annevk for thoughts from the Fetch perspective, as I think folks are interested in starting to poke at an implementation in Chromium.

[annevk]

Do we need to care about anything but top-level navigations? I think if we allow the mixed content behavior to differ depending on whether the switch to HTTPS was opportunistic that ought to be codified somehow.

(Another problem might be that Mixed Content Level 2 hasn't been integrated yet?)

[christhompson]

I think scoping this to top-level navigations makes sense (and has kind of been how I've been thinking about this, although that may be partially due to Chrome's implementation here). If we see mixed subframes as a breakage problem, then we could think about autoupgrading them as part of Mixed Content.

[ericlaw1979]

I remain concerned about Chrome's handling of file downloads, whereby http-sourced downloads are silently blocked, even if the target site is HSTS [1].

I was hoping that we could fix that here. Given the success of things like auto-upgrade of mixed content passive resources, why do we need to limit this to just top-level navigations?

(I worry that doing so might even end up introducing bugs, as we end up with mixed content blocking in cases where the content would not have been mixed if not for the top-level upgrade).

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=1259659#c7

[mozfreddyb]

I see value in this proposal. Firefox is shipping relatively similar behavior in Private Browsing mode - we call it "HTTPS First" and upgrade top-level navigations (with a fallback).

[christhompson]

we end up with mixed content blocking in cases where the content would not have been mixed if not for the top-level upgrade

I would consider this to be a form of breakage and as we experiment with our implementation we plan to monitor cases like that. I think the main concern here is subframe navigation, right? Blockable mixed content (e.g., scripts) would be separate from any navigation upgrading, but maybe with HTTPS Upgrades we should revisit whether to upgrade more content types.

I remain concerned about Chrome's handling of file downloads, whereby http-sourced downloads are silently blocked, even if the target site is HSTS

Agreed that this is a problem. I'm hoping that we can address this as part of our work on Chrome's HTTPS-First Mode and HTTPS Upgrades (they will share a lot of common code), and hopefully that will also apply for sites with HSTS.

(Separately, there is currently an unfortunate interaction between Chrome's handling of HSTS and HTTPS-First Mode, see https://crbug.com/1294328 -- that is also on our hotlist of known issues to fix.)

[mozfreddyb]

we end up with mixed content blocking in cases where the content would not have been mixed if not for the top-level upgrade

I would consider this to be a form of breakage and as we experiment with our implementation we plan to monitor cases like that. I think the main concern here is subframe navigation, right? Blockable mixed content (e.g., scripts) would be separate from any navigation upgrading, but maybe with HTTPS Upgrades we should revisit whether to upgrade more content types.

Same for content upgraded through Mixed Content (i.e., audio, video, img), right?

[annevk]

Right, what happens for both subresources and nested navigations is an important consideration here.

http://a might also be available as https://a, but that does not necessarily mean that https://a has an HTTPS link for http://third-party.example/script. Having said that, it seems vastly preferable to follow established Mixed Content rules and not invent new semantics based on whether the user navigated to https://a directly or via http://a. That might lead the way to side channel attacks and confused web developers and end users.

[christhompson]

To try to clarify the different Mixed Content cases as I see it:

• If the main frame is HTTPS (either explicitly or via HTTPS Upgrades succeeding), then Upgradeable mixed content will be upgraded to HTTPS (without fallback) and Blockable mixed content will be blocked. No HTTP subresources will be fetched, and no HTTP subframes will load.
• If the main frame is HTTP (either explicitly due to allowlisting or fallback), then no mixed content rules apply, and no subresources/subframes are upgraded to HTTPS.

Thus we are treating HTTPS Upgrades and Mixed Content Level 2 (with autoupgrading) as complementary systems that together give the property of no unnecessary plaintext requests. (With Chrome's opt-in HTTPS-First Mode, this gets a bit stronger as "no plaintext requests without user warning", roughly.)

This does mean that on an upgraded page there may be subresources/subframes that are now blocked and may cause breakage on the page. This is a known risk of upgrading top level navigations to HTTPS, but we think the risk is low. Previously when working on Mixed Content Autoupgrading we had considered whether to also make active subresources (e.g., JavaScript) be Upgradeable -- we ultimately decided against this as we felt there was some possible risk to a JS resource differing between HTTP and HTTPS (more than the risk of breakage for just blocking the subresource load). It might be worth reconsidering whether more subresource types should be changed to be Upgradeable instead of Blockable.

We have considered whether HTTPS Upgrades should imply a stronger property to the page load, such as enabling upgrade-insecure-requests, or if this could eventually allow us to deprecate UIR entirely. I think exploring these possibilities are interesting but better left to future work in this space.