Using corridor, a Tor traffic whitelisting gateway with Qubes-Whonix

News
1

Originally published at: News - Whonix Forum
corridor is a Tor traffic whitelisting gateway. It is a filtering gateway. Not a proxying gateway.

It can also be used as a BridgeFirewall.

This is not necessarily more anonymous. It is an additional fail-save Tor traffic whitelisting firewall that would protect from accidental clearnet leaks (hypothetical clearnet leak bugs in Whonix). As corridor’s project description states, quote “it cannot prevent malware on a client computer from finding out your clearnet IP address”. corridor is mostly useful for developers and auditors of Whonix, perhaps also for advanced users who would like to have an additional safety net. It cannot protect from hypothetical Qubes ProxyVM leak bugs either, a physically isolated, standalone corridor-Gateway would be better and could cover that.

It does not increase the tunnel length, i.e. it does not add more relays between you and the destination, if you are interested in that, see Tunnels/Introduction.

Credits: The author of corridor is rustybird. The author of fork of corridor for Debian which will be used in this instructions is Patrick Schleizer.

The full documentation for doing this can be found here:

If you like Whonix, please support it.

3 Likes
2

Great to see this idea progressing. I have an idea about how Corridor can implement a “hardened” mode beside its current safety net model.

It can add an optional setting that locks outgoing connections to the guard(s) chosen by the Tor client instead of merely whitelisting all Tor traffic which can be abused by malware speaking to colluding guards.

At first it will seem like a Whonix-light firewall but when considering that only whitelisted commands make it to Tor on the GW it becomes a second line of defense in Whonix and not just a safety net like on a single system setup.

EDIT:

Supporting multi torrc/guard files for locking can be useful outside the Whonix context when There is a system-tor and tbb Tor running at the same time and you want to whitelist their guards.

1 Like
3

corridor-gateway’s Tor does not have access to sys-whonix’s Tor. So this is difficult to know for corridor-gateway.

Perhaps corridor could limit it to manually configured IPs. I wonder if that would still require corridor or a simpler firewall. It would break when sys-whonix’s Tor automatically (by Tor default) moves to the next Tor entry guard.

You can already do this by using bridges. Then corridor-gateway would act as a bridge firewall:

Even if it had. I am not sure what that would gain.

sys-whonix does not have access to corridor-gateway’s Tor. And would sophisticated attacks it would not need to. sys-whonix, once compromised, could just run getinfo address and game over. Other attacks mentioned on BridgeFirewall · Wiki · Legacy / Trac · GitLab also apply.

Btw I am not the one to convince here. The one that would receive the feature request / pull request would be upstream:

GitHub - rustybird/corridor: Tor traffic whitelisting gateway

Feel free to convince me here anyhow, since that might help writing a good feature request.

Since corridor uses sh for its config files that should already be possible for bridges:

BRIDGES1=`grep -Ei '^[[:space:]]*Bridge[[:space:]]' /etc/tor/torrc`
BRIDGES2=`grep -Ei '^[[:space:]]*Bridge[[:space:]]' /path/to/other/torrc`
BRIDGES="$BRIDGES1
$BRIDGES2"
4

I see. That wasn’t entirely clear from the documentation. (I am also unfamiliar with Qubes architecture). I thought the corridor firewall is installed on the GW VM.

My idea of how it worked:

Internal Network → |GW eth1 firewall| → Corridor firewall → |GW eth0 firewall | → Clearnet

Is this a Qubes thing or is there an intermediary VM sitting between WS and GW for all Whonix editions? IMO that would be a bit resource intensive. If its on the gateway then the bridge/guard lock thing can be done?

The gain is a simpler firewall that is very conservative with rule changes that can guard (and log) leaks that are mistakes or intentional that eth1 firewall didn’t catch.

Right. I want to see if we are onto something here that can serve many purposes before talking to upstream. I don’t want to make a dumb request.

1 Like
5

No. Absolutly not. Start thinking with the upstream defaults from GitHub - rustybird/corridor: Tor traffic whitelisting gateway. This has been adjusted as an additional VM. Whonix-Gateway not connected directly to the internet. But connected to a corridor-Gateway instead.

sitting between WS and GW

This is not possible. This is not for what corridor is designed.

What would be possible is:

  • corridor-workstation → corridor-gateway

In Such an setup it would be up to the corridor-workstation to establish its own Tor circuits. But this would come with all the disadvantages that corridor lists for itself:
GitHub - rustybird/corridor: Tor traffic whitelisting gateway

Quote corridor readme:

“corridor is not a replacement for using a well-designed operating system on your client computers, like Qubes with TorVM/Whonix.”

It is a supplement.

So when Whonix comes into play to, Whonix-Gateway should establish its own Tor circuits and then have a corridor-Gateway as a safety net checking that Whonix-Gateway does not try to establish non-Tor connections.

Qubes does not have networking on the host for security reasons. (In Qubes, the host is called dom0.)

[Which is great, because then the many and diverse wifi / lan drivers do not run on the same system, in kernel mode (!), together with everything else such as private gpg keys, but in an isolated NetVM.]

[And yes, Qubes host can be updated, networking and package download is done in a VM, just package verification and installation of Qubes host updates happens on Qubes host.]

So for Qubes only two things are possible:

  • sys-corridor intermediary VM sitting between GW and sys-firewall
  • sys-whonix → sys-corridor → sys-firewall → sys-net → internet
  • anon-whonix → sys-whonix → sys-corridor → sys-firewall → sys-net → internet
  • standalone, physically isolated corridor-Gateway

https://phabricator.whonix.org/T524#9510

For Non-Qubes-Whonix, installing corridor in a VM is not that useful. More useful:

That is not how it works.

A separate firewall - corridor - running on a different system is a safety net and leak tester for Whonix-Gateway. It cannot be combined with Whonix-Gateway.

What could be done would be making Whonix’s firewall more complex. Rather than “user debian-tor on Whonix-Gateway can establish any [IPv4] connection” it could be limited to “debian-tor may connect to Tor’s current entry guard[s] or bridge[s]”. Perhaps reusing some code that corridor is using. That would not be a “additional safety net and leak tester for Whonix-Gateway”, since that would run on Whonix-Gateway.

6

A more generic introduction into corridor: