How to access local HTTP service from Tor Browser?

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):// running in your local or any other VM. Related:

  • Theoretically: Yes.
    • As per Self Support First Policy for Whonix.
    • Question rephrased to:
      • Is there a way for Net Qube in Qubes to recognize a specific URL and redirect it to some locally running HTTP server?

      • But the actual and better even less specific question would be:
        • Is there a way for socks proxy to recognize a specific URL and redirect it to some locally running HTTP server?

Really difficult.

  1. exercise this on (Qubes) Debian (unspecific to Qubes, Whonix, Debian)
  2. wretch your own, additional socks proxy between Tor Browser and a Tor SocksPort (difficult exercise in itself)
  3. do the filtering (redirection) at with the custom socks proxy

Basically you would need to MitM your own Tor socks traffic.

Or you’d need to fork Tor to add such a feature.

Actually 1 more things comes to mind.

Tor’s MapAddress feature might actually do that without need for an additional socks proxy doing the filtering. See Tor’s man page about the feature.

This feature was used in a different context here:
Blacklist Outgoing Connections to Select Domains

MapAddress some-fake-domain-name.tld

This should in theory redirect some-fake-domain-name.tld to 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.

Hm. Maybe I didn’t explain correctly.

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?


  • No need to bypass sys-whonix
  • No need to modify TB settings in an unsafe way


  • 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

Fake IP vs fake DNS shouldn’t matter as long as you don’t use a fake IP blocked by default by Tor because it’s a LAN IP.

Tor is capable of resolving DNS.

Not possible.

Normally done by accessing the HTTP server on localhost but localhost connections is what’s blocked by default in Tor Browser.

HTTP basic authentication if Firefox supports that for this kind of connection or Onion Services Authentication. Getting more and more complicated.

Not really local but a round-trip through Tor.

Using mapaddress or programmatically seems safer and easier.

1 Like

Yeah, the .onion service is a bad idea.

Using mapaddress or programmatically seems safer and easier.

Re. MapAddress:

IIUC, it is a form of DNS filter which maps fake.tld to So, TB will still try to connect to 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.

TB will proceed without noticing. You will have bypassed that restriction.

1 Like

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.

Therefore MapAddress to a local IP would be better.

So, we are actually back to what was suggested in the OP and rejected (a separate VM for the HTTP service)?

The MapAddress approach doesn’t seem to work (or I am doing something wrong).


  1. Shut down sys-whonix
  2. Clone it to sys-whonix-2
  3. Start sys-whonix-2 and add to /usr/local/etc/torrc.d/50_user.conf:
MapAddress foo
  1. Restart the tor service and run
mkdir -p /tmp/ttt
cd /tmp/ttt
python3 -m http.server 8080 --bind
  1. Boot a VM based on Whonix-workstation template with a netvm=sys-whonix-2 and start TB in it
  2. Try to open http://foo:8080


TB says:

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 = false in about:config - same result)

P.S. This, however, works:

user@host:~ > tor-resolve foo

If Patrick says highly recommended then I take that serious.

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 =” and TB attempts to connect to - which is not possible.

Proof (inside the AppVM using sys-whonix-2 as netvm):

user@host:~ > traceroute foo
traceroute to foo (, 30 hops max, 60 byte packets
 1  localhost (  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).

Outside of Whonix = don’t use any Whonix.

Makes sense. Then this approach reached an impasse.

1 Like

So far, what works fine is:

python3 -m http.server 8080 --bind

in combination with network.proxy.no_proxies_on= as TB preference.

The only remaining issue is how to make this temporary (i.e. only shortly upon browser start), then kill the server clear the preference.




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?

1 Like

Guys, I made it!

Here is the trick:

  1. I created a bash script which kills the HTTP server upon successful GET of the URL with the filters (a few seconds after it)

  2. 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 (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.


Nice finding!

Probably also could use a test that confirms success and shows an error on failure. Otherwise filter list updates could be probably easily missed.

Maybe also useful to split this into several standalone bash scripts.

  • (tor-)browser-local-connections [enable|disable|status]

Probably also could use a test that confirms success and shows an error on failure. Otherwise filter list updates could be probably easily missed.

What do you mean?