Synchronizing guard nodes

Support
1

I run tor on several computers, one whonix the others not, all using the same public IP. What’s the best way to get them all to use the same guard node?

I know I can run one tor client and tunnel all SOCKS to it but that machine must have most trusted status. This doesn’t work for me because I only have one computer on 24/7 but it runs a public-facing server, so it is least trusted. Conversely I run whonix on my most trusted machine but rarely.

I don’t know the significance of everything in /var/lib/tor, are there particular files that should be kept on the same machine, and files that can be copied to clients connected simultaneously?

Possibly related: I run Gateway and Workstation from immutable drives with shared folders for user data, and only reboot briefly into normal mode and no shared folders to apply updates. Will this cause any problems?

In the article on Tor Entry Guards
http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Tor_Entry_Guards

Can someone elaborate on this?
Suppose I pick a guard node to use for sensitive connections. If it is evil I lose. Then there is no harm in routing non-sensitive connections through it as well. I use tor for most web activity and I think it’s better to have constant traffic to one guard than constant traffic to one guard and sporadic traffic to another.

2

We’d like to hear good ideas about that from you. It’s a hard problem when you’ve got strong isolation between VMs on purpose.

If you occasionally boot into persistent mdoe to allow guard rotation after a few months then it should be OK. Using live mode from the very first run is not recommended because Tor will be picking a new guard every time you boot the VM.

Its not abut sensitive vs non-sensitive but Tor Browser traffic should have its own guard, Thunderbird another guard and so on. All browser traffic of all types should be done thru the first guard.

3

I only use the one Gateway. My intention was to have the bare metal linux boxes, including the host, just copy what the Gateway does. But I don’t know exactly how to do that.

Guard rotation was the main reason I stopped using TAILS. That and an almost fanatical hatred of a certain desktop environment.

I’m still not sure what the argument is for separate guard nodes. Is it that different applications can be fingerprinted, identified, and correlated?

4

As per Self Support First Policy for Whonix this question could be rewritten by removing the Whonix specific part from it.

I run tor on several computers, all using the same public IP. What’s the best way to get them all to use the same guard node?

[0] Then this question could be redirected at upstream, The Tor Project, the developers of Tor.

Same as above.

Yes, under the assumption of always strictly syncing the guard relays, these will likely desync because you don’t know when Tor does Tor guard relay rotation.

[1] As long as Tor does not do guard relay rotation, everything is fine. But once you boot non-persistently and Tor think it’s time to switch Tor guard relays, it will pick a Tor guard relay randomly. And other one randomly after next boot. And another one. Until you boot into persistent mode so Tor can store which guard relay it switched to.

Also best to ask upstream. [0]

1 guard/client per internet-connected program (not identity!)

I never really understood that either. What’s so great about per-program (mostly browser nowadays, no?) or type of traffic vs identity.
Or perhaps I did understand that earlier and forgot by now. Dunno anymore where this was discussed previously. Might be found through search.

Same issue as explained under [1].

[2] Perhaps manually choosing Tor entry guards could accomplish that. But I wouldn’t advice doing so without consulting upstream [0] beforehand either.

You’d still have a rare Network Fingerprint from perspective of the ISP.

Even if using the same Tor entry guard, it may be possible to notice that you are running multiple Tor clients at the same time due to re-download of the Tor consensus more often than users who are only running a single Tor client.
Not sure that matters for you.

Another alternative with caveats:

caveats:

source [tor-talk] anonymity: bridge users vs. entry guard users

… They’re probably more vulnerable, but I don’t know if I’d say
“sufficiently”. …

If upstream [0] thinks his makes sense at all, then it could be argued that Tor has a missing feature. A feature that allows to start a read/write Tor client, which is allowed to write to /var/lib/tor folder, as well as other Tor clients which are started in read-only mode, which only consume data in /var/lib/tor folder but do not try to write to it.

Once such a feature was implemented the /var/lib/tor folder could be shared over network mounts. But that sounds really complex. I wouldn’t have too much hope for that to materialize ever. A more realistic approach would be [2].

1 Like
5

Thanks for your reply. I hadn’t considered the regular rotation in immutable mode.
I go into persistent mode for each apt upgrade which isn’t infrequent, so exposure is limited to a few extra guard nodes per cycle, but that’s still a few times as many nodes!
I had to write a script to make this less tedious on VirtualBox but I see now there’s a live mode which I never noticed before.
It sounds like it accomplishes the same thing (except the drive must be read-only and changes are stored in guest RAM vs disposable snapshots in host tmpfs).
But it has the advantage that the guest can tell it’s in read-only mode. When it’s time for a guard change in this case it should show a warning at least. Would it make sense to delay the change for a short time and refuse to bring up eth1 on boot if it’s overdue?
One could mount /var/lib/tor separately but this would likely defeat the point of immutability if compromised.
In the meantime I guess I will leave the Gateway in persistent mode.

6

Bug Reports, Software Development and Feature Requests

Disable Tor networking DisableNetwork 1 instead re-using existing source code.

Dev/git - Kicksecure

7

A complex concept can be -
incron on the GW monitoring the changes to Tor var folder. Triggers a copy action to the shared folder when changes detetced.
Incron on the host overwriting the Tor config folder when modifcation detected.

Less danger of unmasking all of your activities even if you happen to pick a malicious guard.

1 Like
8

A post was split to a new topic: tor-ctrl - Tor control port command line tool