Vanguards - Tor Anonymity Improvement
Donate
Protects against Tor guard discovery and related traffic analysis attacks.
Update[edit]
Update: Due to upstream bugs discussed in https://forums.whonix.org/t/connections-drop-on-tor-0-4-8-9/17702
unfortunately vanguards has been disabled by default.
- https://github.com/mikeperry-tor/vanguards/issues/100
- https://gitlab.torproject.org/tpo/core/tor/-/issues/40892
Quote March 2024:
- Mike Perry assigned to @mikeperry 2 months ago
- Mike Perry added Next label 2 months ago
Introduction[edit]
The vanguards specification overview notes: [1]
This document tries to make the above guard discovery + compromise attack harder to launch. It introduces a configuration option which makes the hidden service also pin the second and third hops of its circuits for a longer duration. With this new path selection, we force the adversary to perform a Sybil attack and two compromise attacks before succeeding. This is an improvement over the current state where the Sybil attack is trivial to pull off, and only a single compromise attack is required. With this new path selection, an attacker is forced to do a one or more node compromise attacks before learning the guard node of a hidden service. This increases the uncertainty of the attacker, since compromise attacks are costly and potentially detectable, so an attacker will have to think twice before beginning a chain of node compromise attacks that they might not be able to complete.
In his July 2018 blog post Announcing Vanguards for Onion Services, Tor developer Mike Perry provided a simpler description of vanguards: to protect against guard discovery and related traffic analysis attacks. This add-on is useful for general Whonix users, since it affords additional protection for Tor clients and Tor onion services (underline added):
We believe that the most serious threat that v3 onion services currently face is guard discovery. A guard discovery attack enables an adversary to determine the guard node(s) that are in use by a Tor client and/or Tor onion service. Once the guard node is known, traffic analysis attacks that can deanonymize an onion service (or onion service user) become easier. ... 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.
Whonix Vanguards Adoption[edit]
From Whonix version 15.0.0.8.7 and above, vanguards is installed by default. It should be noted that a recent Tor vulnerability affecting onion services is sufficiently mitigated by vanguards; see Tor CVE-2020-8516 Hidden Service deanonymization:
The daemon in Tor through 0.4.1.8 and 0.4.2.x through 0.4.2.6 does not verify that a rendezvous node is known before attempting to connect to it, which might make it easier for remote attackers to discover circuit information.
Tor developers have recently developed a proposal for "Vanguards lite". This is identical to the existing proposal, except: [2]
- No third layer of guards is used.
- The Layer2 lifetime uses the max(x,x) distribution with a minimum of one day and maximum of 12 days. This makes the average lifetime approximately a week. We let NUM_LAYER2_GUARDS=4.
- We don't write guards on disk. This means that the guard topology resets when tor restarts.
By avoiding a third-layer of guards we reduce the linkability issues of Proposal 292, which means that we don't have to add an extra hop on top of our paths. This simplifies engineering.
The technical specifications of this proposal require further consideration by Whonix developers to determine its suitability for the broader Whonix user population (as it will exist alongside standard vanguards). While removing a third-layer of guards reduces linkability risks and latency, it also makes it easier to launch guard discovery attacks against clients and onion services.
Also note that onionbalance is now available for onion v3 services, [3] see: Cooking with Onions: Reclaiming the Onionbalance. This means onion service administrators can load balance v3 onion services so they have high availability.
Log Analysis[edit]
Quote What do the logs mean?:
This is an experimental addon with many heuristics that still need tuning. Events that represent severe issues are at WARN level. You should react to these events. Warns are currently emitted for the following conditions:
1. When your service is disconnected from the Tor network, we WARN. Downtime can be a side channel signal or a passive information leak, and you should ensure your Internet connection is reliable to minimize downtime of your service as much as possible. 2. When a hidden service descriptor circuit sends more than 30KB, we WARN. If this happens, it is either a bug, a heavily-modified hidden service descriptor, or an actual attack. 3. When you set ExcludeNodes in Tor to exclude countries, but do not give Tor a GeoIP file, we WARN. 4. If you disable killing circuits in the rendguard component, we WARN when use counts for rends are exceeded. 5. With Tor 0.3.4.10 and above, we WARN upon receipt of any dropped/ignored cell.
Events that are detected by heuristics that still need tuning are at NOTICE level. They may be a bug, a false positive, or an actual attack. If in doubt, don't panic. Please check the Github issues
Technical Information[edit]
The full specification for Proposal 292: Mesh-based vanguards can be found here. The vanguards add-on actually has three components: vanguards, bandguards and rendguards. Mike Perry succinctly describes the role of each subsystem:
Vanguards
The core functionality is provided by the Vanguards component which implements the Mesh Vanguards (Proposal 292). This ensures that all onion service circuits are restricted to a set of second and third layer guards, which have randomized rotation times as defined in that proposal. Basically, now all the hops of onion service circuits are pinned to specific nodes instead of sampling random ones from the whole network every time.
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.
Bandguards
Additionally, the Bandguards component of the add-on also checks for evidence of bandwidth side channel attacks, which may be used by the adversary to aid/amplify traffic analysis attacks.
When these attacks are detected, the circuit is (optionally) closed.
Rendguards
Finally, the Rendguards component of the add-on performs analysis on the prevalence of rendezvous points on the onion service side. The rendezvous point is chosen by the client when it connects to an onion service, and some attacks rely on the use of a malicious rendezvous point to aid in traffic analysis.
This component tracks the frequency of rendezvous point use, and when it finds overuse, it optionally closes circuits from that rendezvous point and emits a log message.
See Also[edit]
To learn more about vanguards, consult the following resources:
- basic information about Tor Entry Guards
- the Announcing Vanguards for Onion Services blog post by The Tor Project
- the security readme by vanguards author and Tor developer Mike Perry regarding attacks against onion services and related defenses
- vanguard's technical readme
- Whonix forum vanguards integration development discussion
- Vanguards lite proposal
- Dev/vanguards
Footnotes[edit]
The most watertight privacy operating system in the world.
At
Whonix we value freedom and trust, supporting Open Source and Freedom Software
2012-
2024 ENCRYPTED SUPPORT LP
We believe security software like Whonix needs to remain open source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!