ID: 363PHID: PHID-TASK-6gghk3wpyerbkirfpi6fAuthor: HulaHoopStatus at Migration Time: invalidPriority at Migration Time: Normal
This ticket is for a working/stable workaround for localhost connections
I found the solution I had been really looking for when I made the faulty proposal in https://phabricator.whonix.org/T343
The idea: an iptables entry on the workstation to reroute requests by TBB that consist of an arbitrarily chosen non RFC-1918 private address to localhost, transparently. This tricks TBB into believing its connecting to a normal address when in reality its to 127.0.0.1
This rule can be toggled on or off as any other custom iptables script. It would be off by default though.
Source:
ip, redirect
ip, redirect
2015-06-23 22:21:03 UTC
Do you have it working or is this TODO research?
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? I mean, if <some private ip> is a shortcut for 127.0.0.1, then any website could fingerprint <some private ip> having the same effect as fingerprinting 127.0.0.1.
We’d have the same effect by allowing local connections in Tor Browser in the first place. And the same fingerprinting issues.
Perhaps keeping <some private ip> secret [chosen by user] and making this a user-documentation-only thing?
Or am I totally off the track?
2015-06-23 22:33:26 UTC
Do you have it working or is this TODO research?
Still research as I haven’t tried it yet.
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?
I mean, if is a shortcut for 127.0.0.1, then any website could fingerprint having the same effect as fingerprinting 127.0.0.1. We’d have the same effect by allowing local connections in Tor Browser in the first place. And the same fingerprinting issues.
True. That’s why if we decide to choose the IP this feature would be disabled by default. But the advantage is, we would have something stable for documentation.
Perhaps keeping secret [chosen by user] and making this a user-documentation-only thing?
If we go this route then its best to incorporate it as a whonixsetup feature? That way it would be safe to leave enabled. Its very unlikely a website will automatically scan the entire non 1918 address space with JS and be able to reliably pinpoint that they found services running on the local machine that way.
2015-06-24 17:59:43 UTC
! In T363#5706, @HulaHoop wrote:
If we go this route then its best to incorporate it as a whonixsetup feature? That way it would be safe to leave enabled.
Well, before considering this, it has to work at all.
Its very unlikely a website will automatically scan the entire non 1918 address space with JS and be able to reliably pinpoint that they found services running on the local machine that way.
Why is that unlikely once we apply that solution? That’s maybe just a small function that loops through all ports away.
2015-06-25 01:12:07 UTC
Why is that unlikely once we apply that solution? That’s maybe just a small function that loops through all ports away.
True. It won’t solve the security problems I though it would and so it can’t be enabled by default.
Also it doesn’t make sense as a usability feature because enabling it will need the command line. That would be harder than the documented workaround we have now.
I’ll close this now.