Intent to Ship: Ignore Strict-Transport-Security for localhost

[Eric Lawrence]

Following up on an earlier thread here: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/gGHOmFGEzQ0

Contact emails: eri...@microsoft.com

Explainer: None

Specification: HSTS specification is at https://datatracker.ietf.org/doc/html/rfc6797; this feature proposes an improvement.

Summary

Strict-Transport-Security response headers can cause problems for localhost web servers because STS applies host-wide, across all ports. This causes compatibility problems for web developers testing locally as well as end-users who use software packages that commonly spin up localhost webservers for ephemeral reasons (e.g. communication of an auth token from a web login to a local software package). If one local listener sets Strict-Transport-Security on a localhost response, it will be applied to all subsequent localhost requests regardless of port. We resolve this problem by ignoring Strict-Transport-Security headers on responses from localhost URLs.

Blink component: Internals>Network>DomainSecurityPolicy

TAG review: None

Risks

Interoperability and Compatibility

The expectation is that this will improve compatibility with services that run on localhost by avoiding unexpected interactions across unrelated packages.

Gecko: Shipped/Shipping

WebKit: No signal

Web developers: Positive (https://issues.chromium.org/issues?q=HSTS%20localhost) Web Developers who test their sites locally commonly report problems with Strict-Transport-Security headers applying unexpectedly across unrelated localhost services under tests.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

HSTS upgrades show in the F12 Network pane as "307 Internal Redirect." In the absence of such an upgrade, the 307 is not shown.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? Yes.

Is this feature fully tested by web-platform-tests? No, HSTS is not tested by Web Platform tests. The change is tested by Chrome unit and browser tests.

Flag name on chrome://flags: None

Finch feature name: None

Non-finch justification: None

Requires code in //chrome? All of the functional changes are in /net/ but tests under /chrome/ require updates to use non 'localhost' test endpoints.

Tracking bug https://issues.chromium.org/issues/41251622; CL: https://chromium-review.googlesource.com/c/chromium/src/+/5923046 

Estimated milestones
Shipping on desktop
132
Shipping on Android
132

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status: https://chromestatus.com/feature/5134293196865536?gate=5113092281991168

Links to previous Intent discussions: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/gGHOmFGEzQ0

[Jeffrey Yasskin]

Can you propose a matching change to the relevant standard? It probably makes sense to start by suggesting a change to https://fetch.spec.whatwg.org/#concept-main-fetch, but the editors there might ask you to write an update to the RFC. We can figure out the cheapest way to get that done if they do ask. There's no need to block shipping this on getting the updates finished, but the launch process does say to propose it first.

Jeffrey

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8d6c447c-32ba-46af-b04e-828e69b38322n%40chromium.org.

[Jeffrey Yasskin]

Oh, I see you already filed https://www.rfc-editor.org/errata/eid8153 to try to get the RFC updated. I'm not sure an erratum is the right way to do this, and your last erratum that tried to do similar things, in 2014, got rejected. If they accept this one, that's fine with me. I see they haven't replied to errata on that RFC since 2017, so I'll try to poke someone...

Jeffrey

[Eric Lawrence]

> probably makes sense to start by suggesting a change to https://fetch.spec.whatwg.org/#concept-main-fetch,

> but the editors there might ask you to write an update to the RFC. 

I don't think I understand what change to Fetch would be proposed. The section you flagged has two relevant clauses related to HTTPS upgrades:

  5. Upgrade request to a potentially trustworthy URL, if appropriate.
  6. Upgrade a mixed content request to a potentially trustworthy URL, if appropriate.

Notably, [*.]localhost is already a potentially trustworthy URL: https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy, clause #5.

...which implies to me that the behavior I propose is already what Fetch asks for.

[Chris Thompson]

I think this would be in Step 10 of Main Fetch (Step 5 is for Upgrade-Insecure-Requests):

Set request’s current URL’s scheme to "https" if all of the following conditions are true:

• request’s current URL’s scheme is "http"
• request’s current URL’s host is a domain
• Matching request’s current URL’s host per Known HSTS Host Domain Name Matching results in either a superdomain match with an asserted includeSubDomains directive or a congruent match (with or without an asserted includeSubDomains directive) [HSTS]; or DNS resolution for the request finds a matching HTTPS RR per section 9.5 of [SVCB]. [HSTS] [SVCB]

So maybe just add a fourth condition "request's current URL's host is not localhost"?

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b81818f0-73ef-4703-af4c-8f8fcefd93d2n%40chromium.org.

[Jeffrey Yasskin]

Yes, exactly.

[Eric Lawrence]

Okay, I've proposed a tweak.

https://github.com/whatwg/fetch/pull/1781

[Alex Russell]

LGTM1

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7c28576e-bee4-430e-8a8d-40c9f23fd6c8n%40chromium.org.

[Mike Taylor]

Can we request reviews for Security, Privacy, Enterprise, etc in the chrome status entry?

thx

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA44PQgt3fZopgSBpkv2GxFr9fpOkCbSES6V0tAVK-Un%3DV-YzA%40mail.gmail.com.

[Daniel Bratell]

This seems like a good change, but I notice that it has no flag associated with it. Is there a reason for that (i.e. very hard to implement) or something similar? If not, we should play it safe and have one just in case there are unforeseen consequences.

/Daniel

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1ce4f44c-fde8-4c96-9611-b1a101e4ab3d%40chromium.org.

[Eric Lawrence]

> This seems like a good change, but I notice that it has no flag associated with it

Okay, patchset 8. https://chromium-review.googlesource.com/c/chromium/src/+/5923046

BASE_FEATURE(kIgnoreHSTSForLocalhost,
             "IgnoreHSTSForLocalhost",
             base::FEATURE_ENABLED_BY_DEFAULT);

[Yoav Weiss (@Shopify)]

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/83d14c46-ac56-4820-84b1-09db6e686d90n%40chromium.org.

[Daniel Bratell]

LGTM3

/Daniel