Intent to Implement and Ship: Treat `http://localhost` as a secure context.

[Mike West]

BCCing net-dev@ as an FYI, as this intent changes resolution of the `localhost` DNS label.

Contact emails

mk...@chromium.org

Spec

https://w3c.github.io/webappsec-secure-contexts/#localhost

https://tools.ietf.org/html/draft-west-let-localhost-be-localhost

The TAG reviewed the underlying Secure Context spec before we shipped it; this carveout was covered.

Summary

Chrome will ensure that `localhost` resolves to a loopback address, thereby ensuring that we can safely treat `http://localhost/` and `http://*.localhost/` as secure contexts, just like `https://example.com/` and `http://127.0.0.1/`.

Motivation

Developers generally expect `http://localhost` to resolve to a loopback address, and are generally surprised to learn that it sometimes doesn't. They're even more surprised to learn that we treat `127.0.0.1` and `localhost` differently for the purposes of secure context calculation.

https://tools.ietf.org/html/draft-west-let-localhost-be-localhost aims to resolve that surprise, tweaking the DNS framework slightly in order to explicitly tie the `localhost` label (and its subdomains) to loopback addresses. Doing so will enable us to safely follow the recommendations in https://w3c.github.io/webappsec-secure-contexts/#localhost, treating `http://localhost` as "secure enough" to carve out an exception.

Interoperability and Compatibility Risk

Edge: No signals

Firefox currently considers `localhost` secure, but doesn't seem to ensure that it maps to a loopback address (http://searchfox.org/mozilla-central/source/dom/security/nsContentSecurityManager.cpp#706). They've expressed public support for doing so in the DNSOP thread at https://www.ietf.org/mail-archive/web/dnsop/current/threads.html#20661.

Safari currently considers `localhost` secure, but does not actually ensure that it maps to a loopback address (https://github.com/WebKit/webkit/blob/097bb2a0dd6bdf977f08f24a0a35d2e9789e10db/Source/WebCore/page/SecurityOrigin.cpp#L592).

Web developers: Positive

Ongoing technical constraints

None.

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

Yes

Is this feature fully tested by web-platform-tests?

No. Upstreaming tests for this feature to WPT will be difficult, as it relies explicitly on `localhost` _not_ hitting an external server, like `web-platform.test`, whereas WPT needs to run on a variety of clients, including those which don't themselves host servers.

OWP launch tracking bug

https://crbug.com/589141

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/6269417340010496

Requesting approval to ship?

Yes.

-mike

[Ryan Sleevi]

Mike: Just to clarify, is this 'localhost' the unqualified host, or 'localhost' the TLD?

I mention, because both the Firefox and Safari implementations only allow exact-match to localhost (and, from quick reading, don't seem to handle http://localhost./, with the trailing dot being used to disable suffix search at the resolver), but the IETF and W3C docs reference localhost the TLD.

My belief is we want it for both the bare 'localhost' label and any sub-labels - correct?

[Mike West]

-mike

You're correct on both counts: Safari and Firefox only treat the `localhost` host as secure. I intend to treat `localhost.` and everything falling within `.localhost.` as secure (after ensuring that they resolve to loopback). That's also what's documented in the relevant specs. I'll make sure to file bugs against WebKit and Firefox.

You also hit on something I forgot to mention: we'll also be ensuring that `localhost` does not use any searchlist that might be configured (that is typing `localhost` into the omnibox will never accidentally resolve as `localhost.corp.intranet`).

-mike

[Emily Stark]

Just to clarify, Chrome already treats http://localhost as a secure context, so this change is just the DNS resolution and not a change to what hostnames we consider potentially trustworthy, right?

Chrome *does* consider http://localhost to be mixed content, though, so maybe we can change that as part of this I2I&S? It would be great to be in a more consistent state.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Dfp04%3D1ARP5ZkwQM9uOD18B1%2BjBvm8J1LddNbjc0qJUHw%40mail.gmail.com.

[L. David Baron]

On Monday 2017-08-21 18:06 -0700, Mike West wrote:
> You're correct on both counts: Safari and Firefox only treat the
> `localhost` host as secure. I intend to treat `localhost.` and everything
> falling within `.localhost.` as secure (after ensuring that they resolve to
> loopback). That's also what's documented in the relevant specs. I'll make
> sure to file bugs against WebKit and Firefox.

There are some existing relevant Firefox bugs:

Consider hardcoding localhost names to the loopback address
https://bugzilla.mozilla.org/show_bug.cgi?id=1220810 (WONTFIX)

Stop treating 'localhost' as securely delivered for the purposes of Secure Contexts
https://bugzilla.mozilla.org/show_bug.cgi?id=1346835

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[Mike West]

On Mon, Aug 21, 2017 at 6:43 PM, Emily Stark <est...@chromium.org> wrote:

Just to clarify, Chrome already treats http://localhost as a secure context, so this change is just the DNS resolution and not a change to what hostnames we consider potentially trustworthy, right?

Huh. I was 100% sure that this wasn't the case, but I think you're right: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/weborigin/SecurityOrigin.cpp?q=ispotentiallytrustworthy&sq=package:chromium&l=354. Why did we do that without making the DNS changes? That was a bad idea! :)

Ok, so consider this intent a belated notification of treating `http://localhost/` as secure, and a suggestion that we a) lock down the bits of DNS resolution that we haven't already addressed, and b) also start treating `http://*.localhost/` as secure, which we do not do today.

 

Chrome *does* consider http://localhost to be mixed content, though, so maybe we can change that as part of this I2I&S? It would be great to be in a more consistent state.

Right. Sorry, that was implicit in my head, as the mixed content specification relies on the secure context specification's definitions of "potentially trustworthy", so changing one is tantamount to changing the other. But you're entirely correct that we should explicitly call that out.

-mike

 

[Mike West]

On Mon, Aug 21, 2017 at 7:01 PM, L. David Baron <dba...@dbaron.org> wrote:

On Monday 2017-08-21 18:06 -0700, Mike West wrote:
> You're correct on both counts: Safari and Firefox only treat the
> `localhost` host as secure. I intend to treat `localhost.` and everything
> falling within `.localhost.` as secure (after ensuring that they resolve to
> loopback). That's also what's documented in the relevant specs. I'll make
> sure to file bugs against WebKit and Firefox.

There are some existing relevant Firefox bugs:

Consider hardcoding localhost names to the loopback address
https://bugzilla.mozilla.org/show_bug.cgi?id=1220810 (WONTFIX)

Stop treating 'localhost' as securely delivered for the purposes of Secure Contexts
https://bugzilla.mozilla.org/show_bug.cgi?id=1346835

Great, thanks David!

Also, I need to amend the "Mozilla support" bits of my original post: I've been working with Richard Barnes to get the localhost changes addressed in the relevant IETF group, and I still think of him as Mozilla even though he left the company months ago. Sorry for that confusion. I don't think we have any explicit signal from Mozilla folks on that thread; I'll poke these bugs in the hopes of obtaining that signal.

-mike

[Matt Menke]

The doc doesn't seem to mention proxies (Configured either via PAC or statically).  Are there any planned changes there?  Either way, the doc should probably explicitly mention them.

On Mon, Aug 21, 2017 at 8:45 PM, Mike West <mk...@chromium.org> wrote:

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAKXHy%3DfAuHaPZWgH04GmHsRwmmQfPeSBMUah17bAQLgzEkcCog%40mail.gmail.com.

[Mike West]

I'll add something to the doc. As we discussed, I see two options:

1.  We allow proxies to intercept requests to `localhost`, potentially routing them elsewhere. That has some advantages for developers (Fiddler comes to mind), with some marginal amount of risk associated with proxying `localhost` requests out onto the network.

2.  We bypass proxies for `localhost`, which ensures that it resolves locally. This would be annoying for local development (Fiddler), but would provide stronger guarantees about the transport properties.

I'm leaning towards #1, but I don't have strong opinions about it.

-mike

-mike

[PhistucK]

1 is much better for local development. Fiddler (or Wireshark) is a great tool for identifying server (even local one) issues, no need to break the common use case.

However, I am not sure it should be treated as secure in case it is proxied (this is 3, then ;)).

(Bonus - try and work with Fiddler to automatically provide an HTTPS variant of localhost, seeing as you are installing its certificate anyway and in those cases, the developer can either use HTTP and HTTPS interchangeably when debugging features that need the raw HTTP headers and for features that need the secure context like Geolocation, media devices and so on)

Regarding the Mozilla signals, I would actually consider them as partially (or completely) negative, really, since Consider hardcoding localhost names to the loopback address is marked as WONTFIX.

The fact that Stop treating 'localhost' as securely delivered for the purposes of Secure Contexts is not marked as WONTFIX is also a worrying signal that Mozilla does not agree with this intent.

☆PhistucK

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcP0BWP_qOkbVoGT%2BrtWPJmhdx7S6sdzoub%2BuPX032hJA%40mail.gmail.com.

[fw...@igalia.com]

Hi Mike,

For the record, I just sent an intent to ship to mozilla-dev: https://groups.google.com/u/1/g/mozilla.dev.platform/c/sZdEYTiEBdE

https://www.chromestatus.com/feature/6269417340010496 says "no active development" but I guess it is "shipped in version 83", right?

Do we have WPT tests for these? I was not able to find any at
https://chromium-review.googlesource.com/c/chromium/src/+/598068
https://chromium-review.googlesource.com/c/chromium/src/+/2002584