FYI re: Proposal 332 (Vanguards lite). When this is implemented it looks like it will exist alongside the standard Vanguards option. That means thinking is required about which one will be better for general Whonix users.
Filename: 332-vanguards-lite.md
Title: Vanguards lite
Author: George Kadianakis, Mike Perry
Created: 2021-05-20
Status: Draft
# 0. Introduction & Motivation
This proposal specifies a simplified version of Proposal 292 "Mesh-based vanguards" for the purposes of implementing it directly into the C Tor codebase.
For more details on guard discovery attacks and how vanguards defend against it, we refer to Proposal 292 [PROP292_REF].
# 1. Overview
We propose an identical system to the Mesh-based Vanguards from proposal 292, but with the following differences:
- 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.
# 2. Rotation Period Analysis
From the table in Section 3.1 of Proposal 292, with NUM_LAYER2_GUARDS=4 it can be seen that this means that the Sybil attack on Layer2 will complete with 50% chance in 18*7 days (126 days) for the 1% adversary, 4*7 days (one month) for the 5% adversary, and 2*7 days (two weeks) for the 10% adversary.
# 3. Tradeoffs from Proposal 292
This proposal has several advantages over Proposal 292:
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 and makes paths shorter by default: this means less latency and quicker page load times.
This proposal also comes with disadvantages:
The lack of third-layer guards makes it easier to launch guard discovery attacks against clients and onion services. Long-lived services are not well protected, and this proposal might provide those services with a false sense of security. Such services should still use the vanguards addon [VANGUARDS_REF].
# 4. References
[PROP292_REF]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/292-mesh-vanguards.txt
[VANGUARDS_REF]: https://github.com/mikeperry-tor/vanguards
It seems the Vanguard lite proposal is a tradeoff against security to increase performance and so thereās no need to swtich to it as a default. However it may be useful for users with high perf reqs to know about it in the documentation.
It will also depend on if vanguards will continue to be maintained. I guess that will be our main point of focus. If vanguards is deprecated then we necessarily must switch to vanguards lite.
Low accuracy statement:
Perhaps vanguards will keep being the go-to tool for advanced anonymity.
Maybe the newest/best defenses are only being implemented in vanguards before these features are backported to Tor core (vanguards lite) with restraints on technical implementation feasibility. Time will tell.
Should the developers bring back Vanguards support to Whonix?
From the limited information The Tor Project has, we believe that one user of the long-retired application Ricochet was fully de-anonymized through a guard discovery attack. This was possible, at the time, because the user was using a version of the software that neither had Vanguards-lite, nor the vanguards addon, which were introduced to protect users from this type of attack. This protection exists in Ricochet-Refresh, a maintained fork of the long-retired project Ricochet, since version 3.0.12 released in June of 2022.
Vanguards-lite, released in Tor 0.4.7, protects against the possibility of combining an adversary-induced circuit creation with circuit-based covert channel to obtain a malicious middle relay confirmed to be next to the userās Guard. Once the Guard is obtained, netflow connection times can be used to find the user of interest. In this case, the netflow attack could proceed quickly, because the attacker was able to determine when the user was online and offline due to their Onion Service descriptor being available, combined with the low number of users on the discovered Guard.
Roger Dingledine pinged you in the tor broken with vanguards issue on GitLab. I assume they are taking this more seriously now after the recent de-anonymization of a Tor user.
One of the users commented on the Gitlab issue claiming that the issue has been fixed. I can confirm that I have enabled vanguards on the Whonix-Gateway and still find that the issue persists on the Whonix-Workstation. My platform is Whonix running on VirtualBox Windows. The issue might be or might not be fixed for other platforms running Whonix.
Thanks, sorry I also forgot to mention that I am running the latest tor version (0.4.8.12). I also find it very shocking that they have not implemented a fix even though this issue has existed for more than 9 months.
This version is still a confirmed issue and quickly drops the Tor connection in Whonix when downloading a 5mb test file when using Obfs4 bridges. This happens when using 1 Obfs4 bridge, it happens when using 2 bridges.
It does NOT! occurs when using a meek bridge. (The download was successful, with no connection drops, although very slow)
I canāt verify if the error occurs without using a bridge
(KVM)
I will make tests with another Tor versions later and will update this post
I canāt edit past post.
Please report to gitlab their this information: after downgrading Tor to 0.4.8.8 the problem disappeared. The test file download was successful
No problem. Just make an additional comment on Tor Project issue tracker. Often better than an edit because edits are more easily missed then new comments.
Nice catch looks like Roger Dingledine has also figured out this issue also which he has commented on GitLab. I was about to build tor from source, commit by commit and run it after the release of (0.4.7.16-1) to find out the reason but you beat me to it. May I ask how did you find out that (0.4.8.8) didnāt have this issue?