I don’t see how that helps to mitigate the issue caused by Firefox?
Access a fake remote domain name?
Fake in this context means “not remote, actually running on your computer somewhere”.
I don’t see how one could sanely reconfigure Tor Browser to visit a http(s)://fake-domain.com/ubo-list.fileformat running in your local or any other VM. Related:
This should in theory redirect some-fake-domain-name.tld to 127.0.0.1 where your local web server would be running. Not sure that would work.
I highly recommend to exercise this outside of Whonix first.
If you manage to set that up, I might be able to help with the Whonix specific part (firewall).
But now after having written all of that: This might be fingerprintable too if a remote website added a request to download an image or something from some-fake-domain-name.tld. So maybe that domain name would need to remain private.
A fake-domain.tld is not required. The URI can simply be something like http://10.x.y.z/list.txt, i.e. the actual issue is not the resolving of fake-domain.tld but the inevitable fact that Tor proxy works on IP-level (below DNS).
Speaking of which, another idea:
How about running an .onion HTTP service locally?
Pros:
No need to bypass sys-whonix
No need to modify TB settings in an unsafe way
Challenge:
I don’t know how to do it (I have never created onion services)
I don’t know how to restrict it (to be accessible only locally)
What do you say?
Another possibility (along the lines of what @extraextra suggested):
start HTTP service on boot (/rw/config/rc.local)
enable localhost access (via user.js)
start TB, uBO will auto-update the lists
kill the HTTP service - can be time based for simplicity. uBO updates the lists in a few seconds, so that can be measured
programmatically re-disable localhost access somehow? in order to avoid restarting TB - so far I see this as the only challenge
Using mapaddress or programmatically seems safer and easier.
Re. MapAddress:
IIUC, it is a form of DNS filter which maps fake.tld to 127.0.0.1. So, TB will still try to connect to 127.0.0.1. How is that different from what we already tried?
Re. programmatically changing settings - this might need writing a simple extension. I have never created extensions, so I will have to learn how to do this.
So, IIUC, using MapAddress implies forwarding to a host which is local to the gateway, i.e. the HTTP server would be running inside sys-whonix, where the filter lists would also be stored?
Yes. That is the idea. But please test outside of Whonix first with system Tor (little-t-tor) (Debian’s tor package) first if MapAddress to localhost is possible at all.
Then upon reflection, redirection to localhost on the gateway isn’t the safest solution, because then any localhost ports on the gateway could be accessed. But still useful to test. (You can test this without a functional network connection. So this is safe to test.)
Therefore MapAddress to a local IP would be better. Maybe you could even loop it back to the same workstation VM. Before attempting that, I would suggest to exercise setting up a Tor onion service for testing purposes. First in Debian. Later in Whonix, so you learn about local IP addresses and firewall changes.
MapAddress is certainly the more hacky way to do it. Programmatically seems cleaner. Both seem probably very difficult to impossible for users to accomplish.
Unable to connect
An error occurred during a connection to foo:8080.
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.
It attempts to connect to https://foo:8080 but I couldn’t find a way to prevent that (I tried “Standard” mode, “Don’t enable HTTPS-Only Mode” and setting dom.security.https_only_mode = false in about:config - same result)
If Patrick says highly recommended then I take that serious.
I read the recommendation as to test this outside of Whonix in order not to mess anything up. As you see, I did not touch sys-whonix. I cloned it. The goal was to test whether MapAddress to localhost was possible at all - yes, it is possible. But it seems to me this is a DNS thing, not a routing thing, i.e. TB asks sys-whonix “gimme the IP address of foo”, sys-whonix replies “foo = 127.0.0.1” and TB attempts to connect to 127.0.0.1 - which is not possible.
Proof (inside the AppVM using sys-whonix-2 as netvm):
user@host:~ > traceroute foo
traceroute to foo (127.0.0.1), 30 hops max, 60 byte packets
1 localhost (127.0.0.1) 0.059 ms 0.027 ms 0.026 ms
IOW, attempts to connect to foo don’t go through the gateway but directly to localhost, which makes it impossible to connect to the HTTP server running inside sys-whonix-2 (the essential idea).
I have searched and researched to find info about how to change an about:config preference programmatically. It seems in modern FF versions extensions cannot do that. A potential possibility might be to use native messaging, which allows a locally running app to communicate with Firefox. However, I couldn’t find a single example of anyone who may have done it. Considering the complexity of this, I will not explore this method further and stick to what works.
If the user decides to enable JS, he will also have to remember to disable localhost access to avoid the (IMO, unlikely in a Qubes+Whonix environment) potential threats.
I will go through the whole method again to polish it before publishing the guide but I wanted to ask:
Considering it is both Whonix- and Qubes-specific (uses disposables), should I share it in another thread here or in Qubes forums? What do you think?
I created a bash script which kills the HTTP server upon successful GET of the URL with the filters (a few seconds after it)
I used autoconfig and centarlized management URL through ‘autoadmin.global_config_url’ (can also be file://). The important thing is to use pref("autoadmin.refresh_interval", 1) in the cfg and in the centralized JS file proxy can be turned off without restarting the browser. The “1” in the refresh interval means 1 minute (this is the smallest possible value). IOW, access to 127.0.0.100 (which would have already been killed) will be blocked 1 minute after TB start. So, the same trigger which kills the server can also swap the pref and that’s it.
I will polish the procedure and share full details soon.