Tor provides anonymity to millions of users around the globe which has made it a valuable target for malicious actors. As a low-latency anonymity system, it is vulnerable to traffic correlation attacks from strong passive adversaries such as large autonomous systems (ASes).[1]
While the answer to the question in the title is false, I want to emphasize that the current situation in the Tor network is alarming, and relay operators should be aware of this issue. By aggregating results from Relay Search (a front-end for Onionoo) and sorting them by guard probability, we can observe that, although relays are hosted by different operators with mostly good intentions, many choose cheap Tor-friendly hosting providers. This results in a concentration of control over Tor traffic. Below are the top five networks that pose potential adversaries:
https://metrics.torproject.org/rs.html#aggregate/as (wait for results to appear, then click twice on Guard Probability column)
GP - Probability of a relay hosted there becoming a guard node:
- Hetzner Online GmbH (AS24940) - 17.7458% GP
- OVH SAS (AS16276) - 12.5729% GP
- netcup GmbH (AS197540) - 6.0250% GP
- IONOS SE (AS8560) - 4.2978% GP
- M247 Europe SRL (AS9009) - 2.9061% GP
The Tor Project advises new relay operators to avoid certain hosters:
https://community.torproject.org/relay/technical-considerations/
In my opinion, this recommendation is insufficient. Each new relay in one of the largest networks should be considered harmful to the Tor network rather than helpful, regardless of who decides to run it or how thoroughly that person verifies their identity.
My intent is not to criticize the Tor Project without offering constructive feedback. What should be implemented is a hardcoded limit on guard probability, which should be integrated into the guard node selection algorithm. This limit should not be set at 10% or 5%, but rather calculated based on the average probability across all networks currently hosting Tor relays. If someone wishes to run another guard or middle relay, even on Hetzner, that is acceptable; however, the chances of it becoming a guard should not be influenced by (often artificially inflated by adversaries[2]) advertised bandwidth, which results in high consensus weight. Instead, that weight should be reduced based on the scale of the AS on which the relay operates. This approach may also encourage new relay operators to seek out less popular hosting providers, thereby increasing the diversity of the Tor network.
If you plan to run a new guard or middle relay, please consider the following:
- Choose an AS that successfully operates a few guard relays (sort by the Guard column from the link above, in ascending order).
- Gather more details about the specific AS; using a tool like bgp.tools can help you find the hoster’s website.
- Most of these ASes are either hosting providers or upstreams (colocation providers, etc.). Hosters will often list both dedicated servers and VDS/VPS options on their websites. If you find a colocation provider that does not offer services for individuals, you can look up their downstreams (mostly hosting companies that have purchased colocation) using the Connectivity tab on bgp.tools.
[1] An Extended View on Measuring Tor AS-level Adversaries arxiv[.]org/pdf/2403.08517
[2] MirageFlow: A New Bandwidth Inflation Attack on Tor ndss-symposium[.]org/wp-content/uploads/2024-1133-paper.pdf