In his July 2018 blog post Announcing Vanguards for Onion Services [archive], Tor developer Mike Perry described the basic purpose 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.
From Whonix ™ version 22.214.171.124.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 [archive]; see Tor CVE-2020-8516 Hidden Service deanonymization [archive]:
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.
Readers who wish to learn more about vanguards are recommended to consult the following resources:
- Basic information about Tor Entry Guards;
- The Announcing Vanguards for Onion Services [archive] blog post by The Tor Project;
- The security readme [archive] by vanguards author and Tor developer Mike Perry regarding attacks against onion services and related defenses;
- Vanguard's technical readme [archive]; and
- Whonix ™ forum vanguards integration development discussion [archive].
Also note that onionbalance [archive] is now available for onion v3 services , see: Cooking with Onions: Reclaiming the Onionbalance [archive]. This means onion service administrators can load balance v3 onion services so they have high availability.
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 [archive] to see if any known false positives are related to these lines, and if not, consider filing an issue. Please redact any relay fingerprints from the messages before posting.
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.
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.
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.
This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! Read, understand and agree to Conditions for Contributions to Whonix ™, then Edit! Edits are held for moderation. Policy of Whonix Website and Whonix Chat and Policy On Nonfreedom Software applies.
Copyright (C) 2012 - 2021 ENCRYPTED SUPPORT LP. Whonix ™ is a trademark. Whonix ™ is a licensee [archive] of the Open Invention Network [archive]. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Freedom Software license as Whonix ™ itself. (Why?)
The personal opinions of moderators or contributors to the Whonix ™ project do not represent the project as a whole.