protects against guard discovery and related traffic analysis attacks.
To better understand vanguards it is helpful to have basic knowledge on Tor Entry Guards.
To learn more about vanguards see Announcing Vanguards for Onion Services [archive] blog post by The Tor Project, security readme [archive] by vanguards author Tor developer Mike Perry on attacks against onion services and defenses.
Additional resources include vanguard's technical readme [archive] and Whonix ™ forum vanguards integration development discussion [archive].
onionbalance [archive] now available for onion v3 services , see https://blog.torproject.org/cooking-onions-reclaiming-onionbalance [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.
vanguards is by default in Whonix ™ 220.127.116.11.7 and above.
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.
Useful for both, Tor clients and 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.
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.
- https://github.com/DonnchaC/onionbalance/issues/69#issuecomment-58108608 [archive]
- https://lists.torproject.org/pipermail/tor-dev/2020-January/014142.html [archive] Tor development mailing list - Request for onionbalance v3 pre-alpha testing]
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.
Copyright (C) 2012 - 2019 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?)