run Vanguards on whonix.org

Website
1

I think most things are within your ability based on recent successes! We’re loving your work. Here’s another possibility:

How about implementing the Vanguards Control Port Add-On server side? Works with Tor 3.3 or 3.4 series.

Announcing the Vanguards Add-On for Onion Services | The Tor Project

A traffic analysis side channel can be used to confirm that the malicious node is in fact part of the rendezvous circuit, leading to the discovery of that onion service’s guard node. From that point, the guard node can be compromised, coerced, or surveilled to determine the actual IP address of the onion service or client.

The Vanguards Control Port Add-On

Fixing the guard discovery problem in Tor itself is an immense project – primarily because it involves many trade-offs between performance and scalability versus path security, which makes it very hard to pick good defaults for every onion service.

Because of this, we have created an add-on that can be used in conjunction with a Tor onion service server or a Tor client that accesses Tor onion services.

The add-on uses our Control Port Protocol and the corresponding Stem Library to defend against these attacks. The hope is that it will we will be able to study the performance and functionality of this feature and gather feedback before we deploy these changes in Tor for all onion services and clients.

[…]

This change to fixed nodes for the second and third layer guards is designed to force the adversary to have to run many more nodes, and to execute both an active sybil attack, as well as a node compromise attack. In particular, the addition of second layer guard nodes means that the adversary goes from being able to discover your guard in minutes by running just one middle node, to requiring them to sustain the attack for weeks or even months, even if they run 5% of the network.

Mike Perry (the guru) notes re: bridges →

Without the vanguards addon, these same attacks will work to find the bridge your onion service is using. So using a bridge by itself is not a defense. However, using a bridge with this addon will provide some additional benefit. Namely, if the bridge is not well-known, it can help obscure the fact that your onion service server is connecting to the Tor network, because the traffic from your onion service into the Tor network will be obfuscated. If meek still works, it is probably the best option, but I think meek no longer works well because the major cloud providers started blocking it – April | 2018 | Ars Technica – so obfs4 or basket may be the best choice. I would use two bridges.

And how this prevents some attacks compared to the normal situation →

No, unfortunately as soon as a malicious middle node is chosen next to your guard node on one of the (many) circuits that the adversary creates, a specially timed stream of data can be used to determine that it is in fact present in the circuit and next to your guard, regardless of the number of hops in your path. See the README for more details: vanguards/README.md at master · mikeperry-tor/vanguards · GitHub

No downside, all upside?

2

Ah yes, I was reading this yesterday. Vanguards previously came to my attention on OnionShare but hadn’t read that much into it yet. This article’s been the best overview of the feature I’ve read yet.

Not quite no downside. Someone who wrote the first couple of comments does a pretty good job of identifying what the trade-off being made is - the element of risk is shifted somewhat but not eradicated (still a risk of ending up with a malicious node, but arguably less chance of it (?) and also the burden of effort for that malicious node to perform attacks is, I think, higher…)

I need to read up more on it, and I also need to understand if this is conflicts with Should we use HiddenServiceSingleHopMode for whonix.org server? - as per that thread, we care less about ‘deanonymizing the onion service’ since the whonix.org IP is already known - but we care about not deanonymizing the client, so maybe indeed we need to consider Vanguards for this, and therefore forget HiddenServiceSingleHopMode.

Anyway yes - definitely on my radar to understand and then decide whether to implement. Thanks!

2 Likes
3

I think we probably also can’t use the BandGuards feature since our use case may involve long-lived or very large transfers of data (downloads, mirroring etc).

I’ve asked about HiddenServiceSingleHopMode on the blog post.

2 Likes
4

asn replied on the article:

Onion services with HiddenServiceSingleHopMode enabled do not use entry guards because they don’t benefit from them (since they are not anonymous), hence there is no point for guard discovery attack or deanonymization attacks there

Although we are not using HiddenServiceSingleHopMode right now, the fact remains that the Whonix.org onions are not really ‘hidden’ as they exist in clearnet too and the IP is known. The Whonix infra is in effect a public service and not trying to ‘hide’, it instead is there to allow users to privately visit the infrastructure.

Accordingly, and noting the response, I’m not sure Vanguards are worthwhile for our use case.

Guard discovery/deanonymisation of the server side is not in our threat model (same reason we are/were considering the HiddenServiceSingleHop mode), and that’s what Vanguards, when employed server-side, protect.

But it may make sense for users to use Vanguards client-side.

That’s my understanding, but I might have it wrong, so welcome thoughts from others.

1 Like
5

It is interesting to note that use of Vanguards probably is distinguishable on the network, same as HiddenServiceSingleHopMode:

The second way your network fingerprint differs when you use this addon is that your guard nodes will see that your Tor client is only connecting to a restricted set of middle hops instead of the whole network (unless you also use that same Tor client to also connect to the external Internet). At this time, there are a lot of other traffic analysis vectors that can be used to fingerprint a hidden service if you control the guard node, though.

This being the case, if we were to implement either option, and both are network distinguishable, and if guard discovery/de-anonymisation of the server side is not a problem we care about (it isn’t), I would choose HiddenServiceSingleHopMode for the performance enhancements.

Because even if the client side’s use of SingleHop mode is distinguishable, they are distinguishable anyway if they are using Vanguards (which they should, to improve their chance of avoiding de-anonymisation by these guard attacks), so ‘distinguishable’ probably can’t be avoided when also seeking extra security.

2 Likes
6

Interesting stuff mig5, thanks for looking into it.

Why not ask directly on either the blog post or tor-talk mailing list i.e.

Hi, I’m currently administrating the Whonix server and v2/v3 onions, and we have been debating the possible benefits of using either:

a) Vanguards server-side; or
b) HiddenServiceSingleHopMode

We understand that option A won’t be very helpful server-side, since the server is not really “hidden” i.e. the IP is known and also exists in clearnet etc, although it might be useful client-side for Whonix users.

In relation to option B, we understand it would provide a performance and stability benefit, but have concerns over possible degradation of anonymity for site visitors:

  • Clients may be statistically distinguishable e.g. malicious nodes identifying single hop user traffic and running exploits to unmask users.
  • Increased DDOS risk and threat of other attacks e.g. intersection attacks (?)
  • These are new features that haven’t matured.

We would appreciate your informed opinion on whether you believe option a) or b) should be configured for a significant performance/security benefit, or whether the status quo is preferable for client anonymity.

1 Like
7

1. Re: Vanguards

mikeperry said

For onion services, the key thing that makes this worthwhile is that the adversary gets to force you to create as many circuits as they like, by continuously connecting to you. So if you are actually under attack, it is strictly better to use restricted second and third layer guards that rotate slower than your circuit creation.

For onion clients, it is a bit more fuzzy since it is harder to get them to build lots of circuits. But, if the adversary only controls a small percentage of the network, you’re still more likely to get lucky than be SOL right away, as you say.

2. Re: hidden services that really want to stay hidden

(perhaps we warn Whonix users configuring hidden services in wiki instructions)

mikeperry said

I’m a little on the yolo side myself but I still deal in science over here. To me, the tradeoffs are clear. If you do not use this addon, the adversary can find your guard in a hot minute (which is much shorter than a wall-clock minute ;), and can use a whole treasure chest of unfixed-in-core-tor attacks to confirm this, observe the guard, and then find your IP address. If you do use this addon, you are making use of the best ways we know of to slow down these attacks. Just a little bit before they go into core-tor.

& (multiple bridges + Vanguard to stymie deanonymization of hosted .onions is better)

Without the vanguards addon, these same attacks will work to find the bridge your onion service is using. So using a bridge by itself is not a defense. However, using a bridge with this addon will provide some additional benefit. Namely, if the bridge is not well-known, it can help obscure the fact that your onion service server is connecting to the Tor network, because the traffic from your onion service into the Tor network will be obfuscated. If meek still works, it is probably the best option, but I think meek no longer works well because the major cloud providers started blocking it – April | 2018 | Ars Technica – so obfs4 or basket may be the best choice. I would use two bridges.

3. Why longer than 3 hops does SFA for anonymity

(we should add to wiki FAQ, as this shit has come up a few times before):

mikeperry said:

July 20, 2018

In reply to just use 4-hop onions as… by Instead of def… (not verified)
Permalink

No, unfortunately as soon as a malicious middle node is chosen next to your guard node on one of the (many) circuits that the adversary creates, a specially timed stream of data can be used to determine that it is in fact present in the circuit and next to your guard, regardless of the number of hops in your path. See the README for more details: vanguards/README.md at master · mikeperry-tor/vanguards · GitHub

And see https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf for the latest research paper on this type of attack.

This is why this addon restricts the number of nodes that can be in the second and third hop, and puts hard limits on the data that can be sent down a Tor circuit that is dropped by the client (and also optionally limits the total amount of data sent on a Tor circuit).

4. Network fingerprinting impact of Vanguards

mikeperry said:

July 23, 2018

In reply to Wouldn’t this be more… by Anonymous (not verified)
Permalink

There are two ways that this addon will alter your network fingerprint.

The first is observable by a local observer watching your connections into the Tor network. They would now see you’re using your two entry guards slightly differently than how stock Tor uses its two guards today. We’re working on making all existing stock Tor clients use two guards in a more balanced way (which is possible with a consensus parameter change), but it takes a lot of effort to convince the whole herd of cats that this should be done sooner rather than later. The hard part is that the counter argument against making all clients use two guards in a balanced way is “Whaaaaa?? I thought Tor was using ONE GUARD. WE SHOULD FIX THAT.” Except making stock Tor actually use one guard is even harder, and opens up more low-resource attacks, too.

While this fingerprinting vector could be eliminated by setting the vanguards configuration option num_layer1_guards to 1 instead of its current default of 2, it turns out that telling Tor to use only one guard as an onion service opens up a very noisy side channel + confirmation attack that can be detected by this same local observer (because it is possible for them to force a “single entry guard” onion service to use a second guard at specific times).

The second way your network fingerprint differs when you use this addon is that your guard nodes will see that your Tor client is only connecting to a restricted set of middle hops instead of the whole network (unless you also use that same Tor client to also connect to the external Internet). At this time, there are a lot of other traffic analysis vectors that can be used to fingerprint a hidden service if you control the guard node, though.

In both cases, I personally feel that the benefit from protecting against guard discovery outweighs the additional fingerprinting risk from these two vectors. And in the long term, we can mitigate/obscure them, too.

Summary

Seems Vanguards are useless server-side for Whonix (unless coming under sustained attack), could be useful client-side, & is essential for those running “hidden” servers and want to really stay hidden (for longer).

The onehopmode no doubt is good for performance, stability etc, so really only the anonymity risk issue for clients is unanswered.

1 Like
8

Seems Vanguards are useless server-side for Whonix (unless coming under sustained attack), could be useful client-side, & is essential for those running “hidden” servers and want to really stay hidden (for longer).

That was the same conclusion I came to as well.

The onehopmode no doubt is good for performance, stability etc, so really only the anonymity risk issue for clients is unanswered.

And even if the use of a single-hop service is statistically distinguishable, so is the act of using Vanguards.

It seems to me the risk of the guard attacks that are mitigated by Vanguards, will likely matter more to clients than the fact that their traffic (note: still anonymized) might indicate they’re visiting ‘a’ single-hop service.

In other words there are bigger problems than a statistically distinguishable visit to a single-hop service vs a regular service. And the use of Vanguards to solve those problems, leaks statistically distinguishable activity anyway (the use of a static selection of l2, l3 middle hops). So if you can’t avoid being statistically distinguishable, may as well protect yourself against the bigger threat, and use Vanguards as a client. And therefore, we may as well use the SingleHop mode if we really think we would benefit from it performance-wise.

But I will ask around indeed just to see if this sentiment is shared… I will also test running the SingleHop mode on our staging server, as I’m curious about the apparent performance benefits and if they’re even noticeable.

Even though I’m crossing topic a bit here, I also am not too worried about the DoS risk of SingleHop mode - again, since the public IP of whonix.org is known, the DoS risk already exists on the clearnet.

2 Likes
9

I read this thread but I am not sure about the final conclusion. I still have some doubts, is it a good idea to install Vanguards if you want to host a hidden server and protect against attacks? If so, do you only need to follow their official instructions to install it in the Whonix Gateway? Or do you need any additional configuration? Maybe I am just asking dump questions but I am trying to really understand it and at the beginning it takes some time…

10

@mig5 is your main person to get a reply from, since he knows what he is talking about. Hopefully he’ll chime in.