HTTPS Upgrades

[christhompson]

こんにちは TAG-さん!

I'm requesting a TAG review of HTTPS Upgrades.

Browsers may still make insecure HTTP requests to HTTPS-enabled sites, unnecessarily exposing data over unencrypted connections. Some browsers ship with lists of sites that are known to support HTTPS, beyond those already in the HSTS preload list. Maintaining such a list is opaque, as it requires web crawler data, and error prone, as it will necessarily be out of date by the time it is shipped to users. It can also be bandwidth intensive, containing thousands or millions of sites that need to be updated. HTTPS Upgrades proposes that the browser should automatically and optimistically upgrade all main-frame HTTP navigations to HTTPS, with fast fallback to HTTP.

• Explainer
• Specification URL (Fetch PR)
• Tests: WPT tests are in-progress
• User research: N/A
• Security and Privacy self-review
• GitHub repo (if you prefer feedback filed there): File feedback on this issue
• Primary contacts (and their relationship to the specification):
  • Chris Thompson (@christhompson, Google Chrome)
  • David Adrian (@dadrian, Google Chrome)
• Organization(s)/project(s) driving the specification: Google Chrome
• Key pieces of existing multi-stakeholder review or discussion of this specification:
  • Gecko: Positive signals (https://github.com/mozilla/standards-positions/issues/800)
  • WebKit: No signal yet (https://github.com/WebKit/standards-positions/issues/185)
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): ChromeStatus entry for this feature

Further details:

• [X] I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: We are hoping to experiment/ship in Chrome 115 which is being released to Stable on July 18.
• The group where the work on this specification is currently being done: WHATWG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WHATWG
• Major unresolved issues with or opposition to this specification:
  • mkwst@ flagged that we should consider specifying the upgrade/fallback as synthetic redirects to more closely align with our implementation (similar to an outstanding Fetch issue on HSTS)
  • There is no previously defined concept for "non-unique hostnames" in Fetch or URL specs, but Chrome exempts these hostnames from HTTPS Upgrades (as they are very unlikely to support HTTPS and can be a source of breakage especially in enterprise configurations). One option would be to give a fairly generous affordance to UAs to exempt hosts as they see fit. Another option would be to try to specify this more robustly so we could align cross-UA on exempting these kinds of hosts.
• This work is being funded by: Google Chrome

You should also know that...

This feature is implemented and can be tested in Chrome Canary/Dev/Beta by enabling chrome://flags#https-upgrades. It uses the same underlying code as Chrome's "HTTPS-First Mode" which can be enabled in chrome://settings/security by toggling the "Always use secure connections" setting.

We'd prefer the TAG provide feedback as:

💬 leave review feedback as a comment in this issue and @-notify @christhompson and @dadrian

[ylafon]

Looks good, however I see potential issues:

In local networks, having http instead of https for some servers that don't have (or want to have) access to the internet is more common, if the host name resolves to a local network, should the speculative upgrade happen in that case?

Also, could there be a http response header put on https-served site to indicate that content on http is not the same and not redirect to https? (ie: to signal that https update should not be done optimistically)

[christhompson]

We've considered ways that we might avoid unnecessary upgrades for local networks (potentially building on top of some of the work that Private Network Access is doing). For now we settled on giving fairly open UA carveouts for exemptions in the spec itself -- Chrome's implementation is using this to exempt non-unique hostnames which we know can't get publicly trusted TLS certificates. For unique hostnames, there are many cases where these do have trusted TLS certificates despite resolving to local network addresses (e.g., the Plex model). On balance, because HTTPS-Upgrades will silently fallback to HTTP if the HTTPS request fails, this might add a small latency to some local network requests but should not cause breakage.

(For Chrome's "HTTPS-First Mode", which shows a full page warning to the user before falling back to HTTP, we are working on ways that we might reduce this warning burden on users for local network requests, but this is still WIP.)

Regarding a HTTP response header: We considered this when we were first proposing HTTPS-Upgrades but decided against it. An "opt-out" header is roughly equivalent to the site serving an HTTP downgrade redirect or just rejecting the HTTPS request (not responding on HTTPS or sending a reset) -- both will trigger the automatic fallback to HTTP. For sites that explicitly don't support HTTPS, we would recommend they serve a downgrade redirect. For the long-tail of sites that won't modify their configs, the new header wouldn't help.

[christhompson]

Following up here to check if there are any other concerns or questions from TAG regarding this feature.

[jeon3029]

Is there any possibility of deleting HTTPS-Upgrades FLAG?

• I am redirecting user request to HTTP because we are supporting iframe HTTP subdomain authorized by samesite-cookie.
  • the domain we are using is private network domain.
• When this options is enabled, We are redirect user request to HTTPS to HTTP(to share cookie between iframe subdomain and origin domain) -> chrome redirect to https
  • So, infinite loop of redirecting happens.

[myakura]

@jeon3029 you might want to chime in on the blink-dev thread. https://groups.google.com/a/chromium.org/g/blink-dev/c/cAS525en8XE

[ylafon]

Regarding a HTTP response header: We considered this when we were first proposing HTTPS-Upgrades but decided against it. An "opt-out" header is roughly equivalent to the site serving an HTTP downgrade redirect or just rejecting the HTTPS request (not responding on HTTPS or sending a reset) -- both will trigger the automatic fallback to HTTP. For sites that explicitly don't support HTTPS, we would recommend they serve a downgrade redirect. For the long-tail of sites that won't modify their configs, the new header wouldn't help.

I don't see this as an opt-out, more an indication that content served through https and http are not the same, so that if an optimistic upgrade to https is done, the browser is aware that it's not the same content. Also it is not a downgrade (as there is no redirect involved)

For sites that don't support https well, then optimistic upgrade shouldn't work, no redirect to http (as in that case it means they support it), unless by don't support you mean have broken configuration, like widely outdated cert, or self-signed one.

[ylafon]

We discussed this during our breakout, and agree that in general it is a good direction (in line with our Secure the Web finding). We expressed our observations but it is not blocking. We also suggest that you ask the IETF http-wg for review. Thanks!