Tor Browser >= 9.0 superficially incompatible with ZeroNet (and most other darknets)

[leycec]

tl;dr

If you recently upgraded to Tor Browser 9.0 and are no longer able to connect to ZeroNet, browse to about:config and change the value of the network.proxy.no_proxies_on setting to 127.0.0.1.

Read on for ugly and terrifying details.

Step 1: Please describe your environment

• ZeroNet version: 7.1
• Operating system: Gentoo Linux
• Web browser: Tor Browser 9.0
• Tor status: always
• Opened port: no
• Special configuration: N/A

Step 2: Describe the problem:

Tor Browser 9.0 (released two days ago) superficially breaks ZeroNet – and all other localhost-based darknets including I2P. Previously, the detailed instructions under the FAQ question "How to use ZeroNet with the Tor browser?" sufficed to render ZeroNet usable with Tor Browser. Tragicomically, Tor Browser 9.0 fundamentally broke us by removing the "Use custom proxy settings" subsection from the "Preferences..." dialog. This includes the "No proxy for:" field required to enable ZeroNet usage. Yup.

The forced removal of custom proxy settings from Tor Browser 9.0 doesn't simply effect new users; it also effects all existing users who previously listed 127.0.0.1 under the "No proxy for:" field. Why? Because Tor Browser 9.0 didn't simply remove these front-facing GUI elements; it also removed all of the underlying implementation logic associated with these front-facing GUI elements.

We begin to see the problem, I trust. Attempting to browse to any localhost port in Tor Browser 9.0 now yields the following thoroughly useless error message:

Unable to connect

Firefox can’t establish a connection to the server at 127.0.0.1:43110.

• The site could be temporarily unavailable or too busy. Try again in a few moments.
• If you are unable to load any pages, check your computer’s network connection.
• If your computer or network is protected by a firewall or proxy, make sure that Tor Browser is permitted to access the Web.

Perusing the Tor logs (e.g., via "Preferences...", "Tor", "View Logs...") yields a slightly more informative view:

10/25/19, 02:33:28.443 [NOTICE] New control connection opened from 127.0.0.1. 10/25/19, 02:33:28.788 [WARN] Rejecting SOCKS request for anonymous connection to private address [scrubbed]. [10 similar message(s) suppressed in last 300 seconds]

This is bad. Since Tor Browser defaults to auto-updating itself, most Tor Browsers users will now find ZeroNet (and most other darknets) inexplicably unresponsive. There's no visual indication during either the Tor Browser update process or from within Tor Browser itself once restarted that localhost connections are now silently and unconditionally denied.

This is appalling user experience (UX) design. This is also disappointing behaviour from Tor Browser developers, who absolutely should know better than to fundamentally break previously working functionality for no demonstrably good reason. Clearly, they think they know better. Clearly, they don't.

I am darknet-based anger incarnate.

I'm afraid I couldn't find a recent ticket on the Tor bug tracker that publicizes this, but several ancient tickets appear to relate: ticket/10419, ticket/10165, and ticket/11493. Please repeatedly pester, flame, and shame developers on the Tor bug tracker until they relent – which they won't, of course. They've only gotten worse and worse and ever more authoritarian "vigilant" about prohibiting localhost access. Expect to be ignored, in other words.

But wait! There's more. As any good Mozilla devotee knows, Firefox's public-facing UI is also overly authoritarian, unnecessarily minimalist, and frankly useless... but trivially circumvented by the One True Preferences dialog: about:config. Long live about:config! Without that, Firefox and now Tor Browser would be literally unusable for most sane purposes.

Does about:config help us here? It absolutely does. Well, until Tor Browser developers realize that users can restore access to localhost by defining a single setting in about:config. At that point, they'll probably attempt to prohibit that, too. When they do, we'll need to get imaginatively creative. Until then, the following alternative instructions to those listed at "How to use ZeroNet with the Tor browser?" suffice to restore worky:

1. Start Tor Browser.
2. Browse to about:config.
3. Enter network.proxy.no_proxies_on into the "Search:" box.
4. Double-click the network.proxy.no_proxies_on line that appears.
5. Enter 127.0.0.1 as the value of this preference.
6. Click "OK".

Changes take effect immediately. Restarting Tor Browser is unnecessary. No thanks for small favours!

Needless to say, we'll need to revise our FAQ instructions to note this. It would be nice [read: it'll never happen] if someone ^{who is not me} would also create a Tor Browser Add-on or Extension for ZeroNet that automates this and other mundane chores (e.g., installing a ZeroNet-specific .pac file for domain resolution).

Until then, we're stuck with low-level manual kludges. Why, developers... Y U break worky!?!?

Steps to reproduce:

1. Update Tor Browser.
2. Note that ZeroNet is dead.
3. Repeatedly smash forehead against keyboard until lapsing into blissful unconsciousness.

Observed Results:

• What happened? This could be a screenshot, a description, log output (you can send log/debug.log file to hello@zeronet.io if necessary), etc.

ZeroNet dead.

Expected Results:

• What did you expect to happen?

ZeroNet not to be dead.

[purplesyringa]

What the heck?

---

As for a serious reply: I'm currently working on a better sandbox for ZeroNet. I guess we should add automatic Tor proxy to it. @filips123 @krixano Do you see any issues?

[purplesyringa]

While ZeroNet in "always tor mode" gives you a warning about that you don't use the Tor Browser and may be your browser is unsafe, I have no doubt that it is perfectly safe.

It is not perfectly safe. Whilst "Tor: Always" blocks outgoing connections on ZeroNet sites, it doesn't block connections made by sites. Using Tor Browser helps fix this.

Do not freak out just because there was an update in Tor Browser.

Uh, seriously? They broke backward compatibility with many decentralized projects (I2P was already mentioned here).

ZeroNet is safe how it is currently

It is not safe. I'm tired of fixing lots of vulnerabilities in ZeroNet code. I'm the one who found several RCEs and private key leak vulnerabilities so you can't just ignore what I say.

Anyways, the main reason to replace the sandbox is not its safety. It's just that it's really difficult to move Clearnet sites to ZeroNet because of some incompatibilities.

you would also probably need to change the target attribute from _top to something else what I also oppose very strongly

Uh, what?.. What target attribute are you talking about?

[purplesyringa]

If you assume that ZeroNet is only secure in Tor Browser than you are wrong

Am I? Try making a zite that accesses some clearnet service to get your IP. That will return correct results in Firefox but a fake (well, almost) IP in Tor Browser.

[ghost]

Since ZeroNet already is in a sandbox doesn't make a difference if you running in Tor Browser or in Firefox.

Actually it does because the ZeroNet sandbox doesn't even protect against everything, LOL.

[purplesyringa]

I see that you have no clue about security or for that matter the sandbox of ZeroNet.

Lmao. You're talking to the guy who found three important vulnerabilities in ZeroNet.

[purplesyringa]

I feel you trying to push changes in ZeroNet because you are selfish and only think about what is good for you

Oh, really? Are you really sure no one needs PeerMessage? (spoiler: look at some PeerMessage-based sites like KxoID or ZeroNetia) Are you really sure no one needs a better sandbox? (spoiler: there were many connected issues recently)

[ghost]

And who's had multiple PRs accepted by nofish, including multiple vulnerability fixes, who's created Git Center, which is used officially by nofish for ZeroNet code as well as various other projects, and PeerMessage which is a pretty useful addition to zeronet (KxoId is based on PeerMessage, 0Play Game Center's chat has instant communication because of PeerMessage), and backgroundprocessing, which is an experimental sandboxing solution for python code.

And anyways... who are you? Are you new to ZeroNet?

[ghost]

If you assume that ZeroNet is only secure in Tor Browser than you are wrong.

Btw, looks like you can't read. imachug said Tor helps fix security issues, he didn't say ZeroNet was completely secure in Tor, just more secure.

because I will going to oppose any of your pulls.

Hm... interesting. You care more about spite than the actual validity or usefulness of his pr's. Anyways... last time I checked, Nofish still has control over zeronet and what pr's are accepted.

Also, last time I checked not everything revolved around you - there are other users besides you who may want these features. Why should they be denied them just because you don't want them, especially considering most things are implemented in plugins and it's very easy to disable plugins now.

Btw, to think that a person only thinks what is good for themselves must only be good for themselves and not necessarily other people is illogical thinking imo. I think most people would say that if they find something useful, then chances are other people will - hence the whole basis of open source.

[ghost]

I don't support any change in ZeroNet source code using the justification that Tor Browser is "broken" ZeroNet. You could run tor locally and use let's say Firefox instead of the Tor Browser.

You're, just wow....

The reason for removing the sandbox has nothing to do with Tor Browser support... this issue didn't even exist before ivanq's issue about removing the sandbox. In fact, ivanq seems to have only mentioned the sandbox removal stuff because of the needed tor proxy.

I'm wondering, perhaps you don't know... all this stuff can't be done with the current sandbox:

1.) Use of client-side router libraries like VueRouter - aka. correct use of History API 2.) ServiceWorkers - needed for Progressive Web Apps and all sorts of things 3.) Every single new browser API that browsers also implement CORS restrictions for has to then be allowed by ZeroNet's sandbox. This clearly would require more management every single time something new is added to JS/browsers - we needed to do this to get Fullscreen working, to get Screen Mirroring, Apple's casting, miracast, and chromecasting working, and probably a few other things, and there's probably going to be more where that came from 4.) Can't use in-browser database 5.) Libraries that use the standard JS APIs won't work because you have to go through ZeroNet's API. We could try to patch every single API JS has by replacing JS functions with functions that call into the ZeroNet API (this was done for XMLHTTPRequest and ajax patching). As far as I'm concerned this is the biggest problem.

Btw, a lot of Tor's features can be done in Firefox with the same or similar addons.

Finally, stop acting like Tor Browser breaking ZeroNet isn't a problem - it clearly is. People other than you use Tor Browser... again, not everything revolves around you. Someone wants to use tor browser and ZeroNet together - and it doesn't matter for what reason - so to them, this is a problem. If this isn't a problem for you, then why the hell are you even talking in this issue, just saying!

Also, stop acting like ZeroNet is completely safe - because your're obviously wrong:

Am I? Try making a zite that accesses some clearnet service to get your IP. That will return correct results in Firefox but a fake (well, almost) IP in Tor Browser.

[filips123]

Uh, seriously? They broke backward compatibility with many decentralized projects (I2P was already mentioned here).

Are you sure that there is no other simple way to use ZeroNet in Tor Browser?

Anyway, I don't think that Tor Browser team thought about this when they removed proxy support. So maybe create a bug to Tor Browser to add support back

[purplesyringa]

Are you sure that there is no other simple way to use ZeroNet in Tor Browser?

An extension might help. Will making an extension real quick and publishing it to AMO help?

[filips123]

An extension might help

I mean built-in way. Tor Browser team probably didn't know that this will break quite a lot of projects, so creating a Tor Browser bug would make sense. Then they could provide another simple (not with about:config) built-in way to do this.

[ghost]

I believe this issue was created to let ZeroNet users know about the about:config workaround, hence:

Needless to say, we'll need to revise our FAQ instructions to note this.

[ghost]

I'm just gonna.... put these here: 2 sandbox escape vulnerabilities, and one html injection vulnerability... in the sandbox wrapper.

---

[monroeclinton]

https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-68.2.0esr-9.5-1&id=b7e28eddd2121a6a8cc5be9fe2c03bf67669bfb3 This is the commit that changed the preferences. I think they were trying to make it so localhost is not proxied by default but it ended up not working. One of the comment said:

By default, proxies don't apply to 127.0.0.1.

When I set network.proxy.allow_hijacking_localhost to false ZeroNet works though. Seems like this is the opposite of what is expected? I might be misunderstanding it though. This is the ticket that changed it: https://trac.torproject.org/projects/tor/ticket/31065

[filips123]

@monroeclinton So it actually is bug in Tor Browser?

[monroeclinton]

@filips123 yeah

[filips123]

@monroeclinton Can you then report it to Tor Browser team if it is not reported already?

[rex4539]

When I asked in tor-dev IRC channel a couple of days ago.

[23:49:41] <rex4539> Is there a way to bypass proxy for localhost in Tor Browser? There used to be a "No proxy for" setting under `about:preferences#advanced` but this setting has been removed.
[23:50:50] <bentham> rex4539: seems like an easy way for websites to determine what software you're running, frankly.  But you're right that Tor is a tool and should let you be in control.
[23:51:19] <GeKo> rex4539: #31065 is your bug i think
[23:51:20] [zwiebelbot] tor#31065: Set network.proxy.allow_hijacking_localhost to true - [closed] - https://bugs.torproject.org/31065
[23:51:46] <GeKo> the pref you need to flip/modify has changed
[23:52:09] <GeKo> but, yes, bentham's point is worth considering

[monroeclinton]

@filips123 I already did, https://trac.torproject.org/projects/tor/ticket/32313. They closed it and pointed to a issue where they said network.proxy.allow_hijacking_localhost is set to true which makes localhost not proxied automatically. The problem is it's not working. This is my understanding at least. If someone wants to reopen my ticket and add to it, feel free.

[filips123]

@matthewrobertbell So ask them back why does it still not work? If this is not desired behavior, they would fix it.

[HelloZeroNet]

I have updated the docs based on the suggestion: https://github.com/HelloZeroNet/Documentation/commit/19f6e9bdada0994d0b8ec18606f8332b2d2de329

[HelloZeroNet]

Can we close this issue as network.proxy.no_proxies_on works fine?