Cooperating Multi-Tor Implementation to avoid Guard Duplication

Why?

Summary: It’s safer to partition activities under different Guard nodes than sticking everything under one guard for a long time in case it’s malicious. More details on the wiki incoming.

Tor inter-VM communication

Implementation outline:

Each Tor runs in it’s own VM and is knwledgeable about the state of the other and avoids using the same guards.

For KVM: Add ivshmem-doorbell device to all gateways. Disable apparmor for gateways VMs to allow communication. Mount and access devices under /dev/. Symlink Tor config on shmem device. Use inotify to copy over new Tor state file when it detects that it’s modified. Taking into account other copies of state files there - a diff operation is run, removing dupe guard entries from either state file which is then detected by inotify and written back to the Tor of one of the VMs.

PROS:

*Straightforward multi-Tor setup with easy isolation.

CONS:

*KVM specific though can have analogue config in Xen. VBox probably not supported.

*Needs fiddling around on host to disable Apparmor isolated between GWs.

*Complex and uses more resources.

*Race condition would need to be resolved for when dupe entries are detected.

Links:

https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg03365.html


One Gateway - Multiple Tors

Implementation outline:
Possible with and without namespaces. Spawning different Tors (under different users that are bound to separate NICs) so each instance can use identical port numbers. Internal networks would be different and use one of its own NICs created on the GW.

A simpler variant of Rusty Bird’s Corridor can then be implemented - Modified to monitor and block duplicate Guard connections as opposed to non Tor connections. Additionally it can trigger a corrective action that resets the state of one of the Tors in question.

PROS:
*Implementation much simpler especially how to resolve dupe guard conflicts. Already based on familiar concepts we use.

*Virtualization platform independent since everything we need is self contained.

*More resource efficient than spawning more VMs.

CONS:
*Theoretically each Tor is not as isolated as the multi-VM approach, but it’s not a deal-breaker if instances are spawned properly and their network resources are partitioned. Also since the GW is part of the TCB it shouldn’t be concerning. Setting CPU/RAM/Entropy limits per process should take care of any potential DDoS attack on other Tors because of a hyperactive malicious workstation that is exhausting Gateway resources.

Links:

Modifying this script can help with creating many Tor instances on the fly:

How to bind each instance to its own NIC:

Corridor can provide code that can be repurposed to filter Guards:

2 Likes

I was just thinking about that, we need to isolates WS usage according to Tors existed in the GW.

e.g:-

  • Distro repo update/upgrade will use Tor 0
  • Browsing will use Tor 1 e.g: TBB
  • Applications will use Tor 2 e.g: Hexchat…etc

Related:-