document Tor Browser local connections workaround

[phabricator-migrator]

Information

ID: 343
PHID: PHID-TASK-inpyl5zaajgrqujrqfxw
Author: Patrick
Status at Migration Time: invalid
Priority at Migration Time: Normal

Description

Tor Browser Local Connections situation is a mess. With no sane (fingerprinting issue free) documented workaround.

! In T291#5255, @HulaHoop wrote:
Or maybe we can use something like rinetd somehow for a safer solution.

Interesting idea. For example, the yacy (or i2p) webinterface could bind to 127.0.0.1:<some-port> (the default, no magic). rinetd (or so) could listen on 10.152.152.11:<some-port> and forward to 127.0.0.1:<some-port>.

TODO:

• #research if that works
• add to documentation
• bonus: (Disadvantage: other workstations can connect to the service listening on 10.152.152.11. A warning needs to be added. But perhaps a separate, virtual, firewalled interface could be added for that purpose.)

Comments

---

Patrick

2015-06-06 01:56:18 UTC

That particular idea of mine is most likely a dead end. Just tried to connect to a webserver listening on 10.152.152.11:80 using Tor Browser. Didn’t work. Tor Browser knows it’s a local IP and rejects it. Therefore also the whole redirection thing won’t work.

But perhaps #iptables magic can do? We could define a fake external IP and then use #iptables to redirect to 127.0.0.1. Just brainstorming. Probably also won’t work. #iptables can’t redirect to 127.0.0.1. That’s what redirectors such as rinetd are for. Also if this were to work, we’d be back with the same fingerprinting issues which Tor Browser wants to defend against by blocking local connections in the first place. So probably not worth it. We’d have the same effect by allowing local connections in Tor Browser in the first place. And the same fingerprinting issues.

Therefore closing this. Anyone feel free to reopen if you have some other solution in mind.