1294402 - Can't access localhost .onion /etc/hosts alias even when blockDotOnion is false

Status: RESOLVED INVALID

(Core :: Networking: DNS, defect)

Description

[infinity0]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160607223741

Steps to reproduce:

Add an alias to /etc/hosts for a .onion address. (It's not a real onion address; that doesn't matter. The server thinks its own hostname is a.b.c.onion, and I'm using the MapAddress feature of torrc to access it as a.b.c.onion from other machines.)

127.0.0.1    a.b.c.onion



Actual results:

Firefox waits forever trying to access the address.


Expected results:

Firefox accesses my localhost server immediately.

This works:

- in previous versions of Firefox
- in the current version, if I use a non-onion alias

This doesn't work, even if:

- in the current version, I set network.dns.blockDotOnion to false

Comment 1

[infinity0]

Same behaviour (i.e. buggy now, but used to work) on Thunderbird 45.2.0 so I guess this is not a "Firefox" issue. But I don't know the best component to move this to; someone else do that please.

Comment 2

[Loic]

Could you install the tool Mozregression to narrow down a regression range, please.
See http://mozilla.github.io/mozregression/ for details.
Run the command "mozregression --good=44" then copy here the final pushlog from mozilla-inbound (or mozilla-central if need be)

Comment 3

[infinity0]

I'm unlikely to have time to do that any time soon. But I can tell you I'm fairly confident this bug was not present in Firefox and Thunderbird 44.

Comment 4

[infinity0]

You can easily reproduce/verify the bug yourself by following the instructions I gave in the first post, as well as verify that it wasn't present in older versions. I'd expect Mozilla developers to be in a better position to do that, since you already have all the necessary build tools set up.

Comment 5

[Loic]

Can I reproduce it easily on Win 7 by just adding "127.0.0.1    a.b.c.onion" to the hosts file?

Comment 6

[infinity0]

I don't know, have you tried it? You also need to set up an actual webserver running on localhost, but that should be fairly simple. e.g. `python -m SimpleHTTPServer`.

Comment 7

[infinity0]

In case you are having trouble locating the hosts file on Windows (yes there is one), see this article: https://support.rackspace.com/how-to/modify-your-hosts-file/

Anyway Firefox shouldn't be reading this directly, but instead using the OS's standard library functions. If Firefox has specific code to read the hosts file, I'd imagine that they would be different on Windows vs Linux. However, I also imagine Mozilla provides you with actual Linux machines to test these things on.

Comment 8

[Loic]

I modified the hosts file by adding:
127.0.0.1       localhost
127.0.0.1	a.b.c.onion

As I have python 2.7 installed on my machine, I'm able to launch a webserver on localhost (default port is 8000) and see any directory in Firefox by opening http://127.0.0.1:8000/

Do I need to set more the local webserver?

Comment 9

[infinity0]

Are you able to see these directories when visiting http://a.b.c.onion:8000/ ? That is the point of the hosts file, after all.

For a clearer comparison, try adding:

127.0.0.1       x.y.z
127.0.0.1	a.b.c.onion

and see that it's possible to access http://x.y.z:8000/ but not http://a.b.c.onion:8000/, even though both are clearly not "real" domain names.

Comment 10

[Loic]

OK, I see the issue you explained in your 1st comment.
After adding to the hosts file:
127.0.0.1       x.y.z
127.0.0.1	a.b.c.onion

the results are:

1) http://x.y.z:8000/ redirects to http://localhost:8000/
2) http://a.b.c.onion:8000/ displays the error page "Server not found".

I'll will a regression range myself.

Comment 11

[infinity0]

Thank you! Sorry I was too terse in my first comment; sometimes one forgets how much context the other person doesn't have. To explain another part of it:

The "network.dns.blockDotOnion" setting in about:config defaults to true. This sounds like it will purposefully block hostname lookups for .onion (Tor onion service) addresses, presumably for security reasons - one probably[*] never needs to do a local hostname lookup that ends in ".onion", since this would never resolve outside of Tor, so better to block it.

However in less-common circumstances such as my own set-up, I *do* want a local hostname lookup for a .onion address. This is presumably why the "network.dns.blockDotOnion" setting exists in the first place, so people like me can turn it off - but this "turn it off" functionality is not working.

Comment 12

[Loic]

Ok, so it's due to bug 1228457 introduced in 45.
But if I set the pref network.dns.blockDotOnion to false, Firefox is able to resolve the .onion address.

Could you test with a fresh profile and network.dns.blockDotOnion=false (restart FF to apply)?
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Comment 13

[infinity0]

Thanks for taking your time to look at this. I've explored my setup a bit more and I can conclude there is no bug with Mozilla. However, users need to watch out for the following:

1. When you set network.dns.blockDotOnion to false, you *must restart* for this to take effect.

2. If you are also using Tor (or another proxy), you need to add your .onion alias (or something that matches it) to the list of "No Proxy For" addresses (or the network.proxy.no_proxies_on setting). This will (a) allow Tor to work, as well as (b) allow your alias to bypass Tor and go directly to 127.0.0.1 (or whatever you set in your hosts file).

In the example above, this would be "a.b.c.onion" or something like ".b.c.onion" if you want a shortcut for multiple addresses. You probably shouldn't add ".onion" to it.

3. If you are using Torbirdy in Thunderbird, it will clear the setting from (2) every time you restart. So you need to either (a) manually set this every time, or (b) disable Torbirdy, or perhaps (c) we can convince the authors to add an option not to do this. But I'm happy with (a) for the time being.

A combination of these factors led me to be slightly confused on what was actually happening here, causing me to file this bug report, but there is no issue with Mozilla. Thanks again for your patience!