Tor Entry Guards

Support
1

I’m quite confused with Tor Entry Guards Whonix wiki article (can’t post the link).

Previously, I was religiously following the rule “less entry guards = better security”, based on Whonix wiki recommendations.

Many well-known, enhanced anonymity designs like Tor, Whonix ™ and the Tor Browser Bundle (TBB) use persistent Tor guards. This decision is attributable to community-based research which demonstrates that persistent Tor entry guards benefit security and lower the probability of an adversary profiling a user.

Creating a new Whonix-Gateway ™ (sys-whonix) will likely lead to a new set of Tor entry guards, which is proven to degrade anonymity.

Forcing the rotation of guards more often than Tor’s default is dangerous for several reasons:

  • It increases the likelihood of a compromised or malicious Tor guard being selected. This raises the chance of a successful correlation attack if the adversary runs Tor exit relays in the network

According to this information, more entry guards = bigger attack surface, higher chance of a compromised Tor guard. So, if you use multiple Workstations with multiple Gateways, it is recommended to use one entry guard for all Tor applications. That is what I always thought before.

Now it is absolutely different:

If I’m correct, Increase Protection from Malicious Entry Guards: One Guard per Application paragraph of the article is fairly new.

It was discovered that 1 guard/client per internet-connected program (not identity!) is the safest possible configuration. In fact, the probability of a network adversary observing a user’s activities is lower than the default scenario, whereby one Tor Entry Guard is relied upon for all applications.

So, I was wrong all the time? Different entry guards should be used not just for every separate identity, but per every internet-connected program?

For example, I have 10 separate identities. Each one of them has it’s Tor Browser, Email, IRC, Jabber and Mumble (5 programs total). According to this recommendation, I should use 50 different entry guards (50 different Gateways)?

@HulaHoop I would be very glad if you could help me to understand this topic.

3 Likes
2

Reading the footnotes of that wiki chapter Increase Protection from Malicious Entry Guards: One Guard per Application might also help finding out where this is coming from.

There are various issues with that wiki chapter.

Increase Protection from Malicious Entry Guards: One Guard per Application

One Guard? Meaning literally a single Tor entry guard (one IP address) only? Not the Tor default which is a set of Tor entry guards. A set meaning multiple.

How many Tor entry guards will Tor use by default? That’s a good question.

Maybe that wiki chapter needs updating anyhow due to some new developments. Namely 1) above forum post by Roger and 2) Vanguards - Tor Anonymity Improvement? I think when that wiki chapter was written that was prior 1) (for sure) and prior 2)?

Increase Protection from Malicious Entry Guards: One Guard per Application

If taking this literally, does it mean 1 guard or leave the number of guards up to Tor?

That wiki chapter might also conflict with the other wiki chapters…

…where we are essentially saying “leave the Tor routing algorithm to the Tor developers”.

In fact, the probability of a network adversary observing a user’s activities is lower than the default scenario,

Why is the probability lower?

What’s the default scenario?

To apply this Increase Protection from Malicious Entry Guards configuration, follow these steps:

  1. Import a Whonix-Gateway ™ into the hypervisor that has never been started.
  2. Take a snapshot and name it “Original”.
  3. Start Whonix-Gateway ™ and wait for Tor to finish bootstrapping (connecting).
  4. After Tor has connected, shutdown Whonix-Gateway ™ and take another snapshot - the naming convention should match the intended activity, such as “Email”.
  5. This snapshot should be used with all Whonix-Workstation ™ snapshots related to/called “Email”, whether it is identity “John Doe”, “Jane Doe” and so on. Note the Workstations should also be generated separately from a clean baseline.

When a separate activity is required such as IRC, users should revert to the Whonix-Gateway ™ snapshot (labelled “Original”), then repeat the same steps. That is, allow it to boot and connect to Tor, shut it down, then take a snapshot entitled “IRC”. Note that if a webpage IRC chat client is used, then this should be done from “Browsing” snapshot.

I don’t think these instructions do actually anything at all. [*] Instructions do not include any step to change any Tor entry guard. By following the instructions as is, the same Tor entry guard will be used for “Email”, “IRC” and “Browsing”.

[*] Before Tor does guard rotation.

In any case, for all of this, very much also this applies:

2 Likes
3

I don’t think these instructions do actually anything at all.

Really, these instructions are nonsense which confuses me even more. It’s either a mistake or the whole “One Guard Per Application” concept is wrong.

That’s why I initially quoted @HulaHoop, because it seems that this idea is based entirely on his discussion with Tariq Elahi.

1 Like
4

Thanks for dropping in. This advice from Tariq of one guard per app/use case supersedes the current conventional wisdom of one guard for everything. It compartmentalizes your activity so even if you were to have a bad guard only part of what you do is exposed while the downside of using more more guards minimally raises the risk of exposure.

Tor’s “default” is of little relevance here since it has no concept of virtualization or different apps. This is an overlay and a product of the way we use it in Whonix.

No let me explain below

No You use 5 different guards only because it’s the number of apps we care about. So five different snapshots of the Gateway started from a pristine condition.

The only time you’d use separate GWs is when you want to multitask and run two activities at the same time rather than firing up a single snapshot *say for email first) doing your thing then restarting the next one for Mumble for example.

1 Like
5
  • I don’t think these instructions do actually anything at all. Meaning, the instructions don’t influence Tor entry guards.
  • This is because the instructions do not include any step to change any Tor entry guard.
  • By following the instructions as they are currently written, the same Tor entry guard will be used for “Email”, “IRC” and “Browsing”.
1 Like
6
1 Like
8

Interested. Found:

'Is the Whonix advice on using multiple guards better than the Tor standard? - General Discussion - Tor Project Forum

No answers yet.
@HulaHoop when you have time please review Tor Forum link. Think discussion presents your position but hate assume.

2 Likes
9

Making the Tor guards page easier to understand is on my long list but eventually I’ll do it. This thread you ink to is unfortunately of littel value since no reputable dev has chimed in, but they need not do so since this question has already been settled by a researcher whose work guides their dev planning.

2 Likes
10

Thank you for taking the time to look.

Good to know. Appreciate response and all your work.

Understood. No worries. Thanks!

1 Like
11

In the case that the app is a web browser then the Tor blog post makes sense, but you could take their advice and also do the 1 app per 1 guard proposal, and get the best of both worlds.

Which blog post was Tariq referring to?

1 Like
12

Clearly missed your question and very sorry did not see it earlier.

Unfortunately I do not know. I did post

based on Tor Entry Guards - Whonix footnote 10

The Tor blog post speaks about website fingerprinting, which is done without the cooperation of a malicious guard or compromising any other Tor infrastructure. Defending against a malicious guard is the attack you have considered. The two are independent and have different properties and usefulness as an adversarial tool.

I describe each here to fix our descriptions of the two things.

A malicious guard can compromise all circuits that go through it, if the honest client also picks (or is somehow manipulated into picking) a malicious exit. Then all traffic on this circuit is compromised with certainty. The rate of success for the adversary is proportional to how much bandwidth she can afford and deploy.

A website fingerprinting adversary can observe and try to identify all Tor traffic flowing out of the client’s machine on the way to the guard. The rate of success for the adversary is proportional to how good the website classifier she has.

The first attack is straight forward. Deploy nodes and enjoy the compromises. The second attack is not so clear. For the former, the compromised guard node can separate out the different flows since it can inspect Tor application level information. For the latter, the problem is that the adversary only has network level information and must do the work of first separating out the flows into individual website accesses. Otherwise WF does not work. The advice that the Tor blog post is giving is to make this separation job harder for the adversary and hence render the WF less effective (i.e. very low accuracy).

In the case that the app is a web browser then the Tor blog post makes sense, but you could take their advice and also do the 1 app per 1 guard proposal, and get the best of both worlds.

There is another consideration, WF works because there is a stable fingerprint to learn (in this case the website that does not change too much and the adversary can generate training data by accessing this website). Is this the case of the apps (other than web browser) you have in mind? Will there be a stable traffic pattern for the adversary to learn? Do you want to hide the fact that the app is being used versus the party that is being communicating with? I think that the blog post is talking about a very narrow problem. Furthermore, there is not yet side consensus on 1) how well WF is actually working in the real world (versus very well known effectiveness or malicious guards) and 2) what the best and practical defences are (where randomly doing lots of stuff at once sounds mostly impractical if not automated and expensive in bandwidth).

Tariq

Maybe @HulaHoop has or can locate a link?

1 Like
13
1 Like