Bug 1220810 (let-localhost-be-localhost)

Consider hardcoding localhost names to the loopback address

REOPENED
Assigned to

Status

()

P3
normal
REOPENED
3 years ago
3 months ago

People

(Reporter: jwatt, Assigned: mcmanus)

Tracking

(Blocks: 2 bugs)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox45 affected)

Details

(Whiteboard: [necko-active])

(Reporter)

Description

3 years ago
See bug 1162772 comment 15. https://tools.ietf.org/html/rfc6761 suggests that we can treat "localhost" specially and should hardcode localhost names to the loopback address:

  "Application software MAY recognize localhost names as special"

and:

  "Name resolution APIs and libraries SHOULD recognize localhost
   names as special and SHOULD always return the IP loopback address
   for address queries and negative responses for all other query
   types.  Name resolution APIs SHOULD NOT send queries for
   localhost names to their configured caching DNS server(s).)."

Not doing that is concerning:

https://twitter.com/sleevi_/status/649025202722967553

Can we do this?

Backstory: I'm implementing an API that allows consumers to determine whether a document was loaded over TLS, or otherwise transported in a way that guarantees authentication and integrity. I can whitelist 127.0.0.1, but I'd also like to whitelist localhost names for the convenience of web developers who are developing content on a local server. If we don't guarantee that they resolve to a loopback address I can't do that though.
(Reporter)

Updated

3 years ago
Flags: needinfo?(mcmanus)
(Reporter)

Comment 1

3 years ago
(Maybe an alternative for me is to use nsIDNSService::Resolve with the RESOLVE_OFFLINE flag, but there's always the possibility that the response at the time I call it was different than at the time the resource was loaded.)
(Reporter)

Comment 2

3 years ago
(And it would be great if nsIDNSService had an IsLoopBackAddress method that took an nsIURI*. I see there's already a method in DNS.h by that name, but it needs an IP4/IP6 address.)
(Assignee)

Comment 3

3 years ago
One problem with hardcoding localhost to be 127.0.0.1 is that it locks you into ipv4.. and conceivably someone could be running a v6 service on only ::1 and be setup that way with the local resolver. (its not that there is a v6/v4 advantage in doing so, but if they've set thing up to bind that way we would break them).

I don't like the idea of resolving the hostname before calling asyncopen either. time of check time of use would be a problem with round robin, etc..

There is also the matter of cached or offline operation. Addresses are lost then.

In general, the security model is defined by origin right .. are we sure localhost isn't sufficient here? If someone has overloaded localhost that would seem to be under local control and acceptable; no?
Flags: needinfo?(mcmanus)

Comment 4

3 years ago
We recently made a similar change in Chrome. Right now we always resolve local hostnames to 127.0.0.1/::1 because we found that queries for "localhost.", "foo.localhost", etc. could go out over the network on several platforms, and/or resolve to non-loopback IPs. In some cases this would be due to an obvious local change (such as resolving localhost to an external IP in /etc/hosts), but not always (such as "foo.localhost" or a suffix search for "localhost").

In Chrome's async DNS resolver we resolve to both 127.0.0.1 and ::1 if the query doesn't specify one or the other. Would that prevent breakage in the case of an ipv6 service that mcmanus mentioned? (i.e. would Firefox try ::1 if 127.0.0.1 fails to connect?)

There are other problems that arise with the approach that Chrome has right now, though. See https://crbug.com/510124, for example. I like sleevi's suggestion there of filtering the addresses returned by the system resolver when possible, rather than skipping the system resolver all together.
Jet asked offline if this was a blocker for bug 1162772. After talking with rbarnes, we don't think so. We can just implement per the spec:

"In particular, the user agent SHOULD treat file URLs and URLs with hostnames names equivalent to localhost as potentially trustworthy." [1]

This would seem to fit with mcmanus' comment #3 - localhost should be sufficient here. Maybe there's an optimization possible, but it shouldn't be a blocker for the secure context API.

[1] https://w3c.github.io/webappsec-secure-contexts/
(Reporter)

Comment 6

3 years ago
It may not technically block, but I think it's still useful to have that relationship linked in case the question comes up in bug 1220687.
Blocks: 1220687
(Assignee)

Comment 7

3 years ago
I don't think I would take this (comment 3) unless it becomes necessary for webcompat. So I'm going to mark it wontfix. If there is a pending patch or strategy (rather than a speculative one) for which its necessary lets talk about what the constraints around that could be in a concrete way. but in general, the os should define what names mean.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 8

2 years ago
So I believe the resolution here means that we should stop treating 'localhost' as secure, per:

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

Is that correct, Patrick?
Flags: needinfo?(mcmanus)
(Reporter)

Updated

2 years ago
See Also: → bug 1346835

Comment 10

2 years ago
Hey folks!

It would be really helpful to get y'all's input on the localhost draft David noted above. There's an ongoing thread in the DNSOP working group (https://www.ietf.org/mail-archive/web/dnsop/current/threads.html#20661) where Richard Barnes has been actively participating. I'd forgotten that he's no longer representing Mozilla, so I didn't think to ping other folks explicitly. :( It would be quite nice if y'all would join in with your opinions (especially if they match mine and Richard's. :) ).
Reopening for McManus to reconsider in the light of the above-linked IETF discussions (and the fact that he seems to be the only one who doesn't want to do this :-) )
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Assignee: nobody → mcmanus
Whiteboard: [necko-active]

Comment 12

2 years ago
DNSOP has opened a Call for Adoption on the document discussed above: https://www.ietf.org/mail-archive/web/dnsop/current/msg20963.html. If Mozilla has some feedback, positive or negative, that would be an excellent thread on which to register it. Comments on adoption are open through the 20th... :)

Comment 14

2 years ago
Ping. Today's the end of the call for adoption for the draft. It would be a lovely time to get some feedback in, if y'all have any. :)

Comment 15

a year ago
DNSOP has moved the localhost draft discussed above to Last Call: https://mailarchive.ietf.org/arch/msg/dnsop/fz5vTiTgH5V7buUkH8adTy2-_5Y

If y'all have feedback, now would be a lovely time to hop into the conversation. :)
:mt do we have a stance on this IETF proposal before comments close on it, It seems like Patrick wasn't keen on it.
Flags: needinfo?(martin.thomson)
I consider this optional for us.  It's only important if we think that we need to mark http://localhost as a secure context.

I'd prefer to do something else/better for people who are developing sites.  But I'll talk to mcmanus.
Flags: needinfo?(martin.thomson)
> I'd prefer to do something else/better for people who are developing sites.

Yeah we have the meta Bug 1410365 specifically for capturing that. :)

> It's only important if we think that we need to mark http://localhost as a secure context.

I'm fairly certain Chrome and Firefox already do this for the webidl meaning of SecureContext given I can access geolocation in both browsers. I think this is what Mike is trying to address with this spec change, either that or we could start treating localhost as not secure once we have other avenues for developers here.

Comment 19

a year ago
> I consider this optional for us. It's only important if we think that we need to
> mark http://localhost as a secure context.

That latter bit is something that y'all are already doing, as jkt notes. It's also something that dveditz@, et al have been supportive of in the WebAppSec WG. If it's not something Mozilla actually wants to be doing, then we need to revisit a few more decisions. I'm not terribly enthusiastic about doing so, given the feedback I've gotten from developers. :)

I'd also note that there are some additional considerations from sunset4 noted in the document's introduction around hardcoding loopback addresses that seem reasonable to address from a developer perspective.
(Assignee)

Comment 20

a year ago
it seems that we're committed to the notion that http://localhost is a secure context. I would have preferred to have found an answer for developers that doesn't use a http:// scheme but I'll acknowledge being in the rough. (as a side note we definitely have features that are restricted to https and need to be migrated to use secure context for consistency).

As mt says, this is impt (mostly?) for sc.

I also appreciate that Mike has taken the time and effort to put this through DNS OP - which is where this kind of deviation should live. We can add it to the .onion catalog of weird exceptions.

This was characterized as hardcode localhost to 127.0.0.1 (perhaps just in the tweet) and that formed part of my concern about 127 vs :1.. emily's comments correctly point to a gecko solution where this can be implemented a bit deeper in the resolver where we are already committed to a/quad-a and therefore return both where appropriate.

So based on current events, I'll adjust my position and say I'm willing to merge a patch along those lines unless we've got the stomach to fight the web-compat issues and go a different way on securecontexts. (reverting what we've got).
Flags: needinfo?(mcmanus)
Moving to p3 because no activity for at least 24 weeks.
Priority: P1 → P3
See Also: → bug 1503393
As it currently stands we don't exempt localhost like we do for 127.0.0.1 from upgrade insecure and mixed content blocking.
Blocks: 1433933
You need to log in before you can comment on or make changes to this bug.