Anyone can run a Tor relay, and on several documented occasions a single unknown operator has run a large share of the network. This research note reviews what malicious relays have done, what the Tor Project and independent researchers already use to find them, and the design of Relay Authority, a score from 0 to 100 for each relay that HisnLabs is building for TorAi, in the way some web tools give a site a single authority number. Relay Authority is in development, no list has been published, and the note ends with what such a score cannot see, starting with an exit relay that only reads traffic and never changes it.
Background
A Tor circuit crosses three relays: a guard, a middle relay and an exit. The Tor Project describes the trade-off plainly: the barrier to running a relay is kept low because that openness makes the network “more robust and resilient to attacks”, but “that low threshold of contributing to our network also makes it easier for malicious operators to attack our users” [4]. Rejecting relays is not done by Tor staff: directory authorities, “run mostly by trusted volunteers”, reject a relay “only … if the majority of directory authorities agree to do so” [4].
What a bad relay can do depends on its position. The exit is the only relay that sees the connection to the destination, and whether it can read or change the content depends on the protocol: plain HTTP is exposed, HTTPS is not [1]. The Spoiled Onions authors list what this allows: “traffic sniffing, DNS poisoning, and SSL-based attacks such as HTTPS MitM and sslstrip” [6]. Guard and middle positions are, in nusenu’s words, “useless for the usual malicious actor manipulating and sniffing tor exit traffic, because in these positions no plaintext traffic is available” [2]. Their risk is of another kind: a guard sees the user’s IP address, and nusenu lists the collection of client IP addresses among KAX17’s plausible aims [2]; an adversary that can observe traffic both entering and leaving the network can correlate the two and identify the user and the destination [16].
Findings
BTCMITM20: exits that rewrote Bitcoin addresses
In August 2020 nusenu described one operator who at its peak ran more than 23 per cent of the Tor network’s exit capacity, so that “roughly about one out of 4 connections leaving the Tor network were going through exit relays controlled by a single attacker”, with over 380 relays running at once [1]. The relays would “(selectively) remove HTTP-to-HTTPS redirects”, and they “replaced bitcoin addresses in HTTP traffic to redirect transactions to their wallets” [1]. The Tor Project’s advisory on the same period confirms the method: the relays left almost all traffic alone and intercepted connections to “a small number of cryptocurrency exchange websites”, and a replacement group appeared after the first was removed, the two offering about 23 and 19 per cent of exit capacity [3].
Two details matter for any scoring design. The operator came back: “It took them less than 30 days to recover after a removal” [1]. And it learnt to look like several honest groups: after a burst of over 150 new relays on 16 March 2020 was removed, the relays were allowed back three days later once the operator declared them as a family, and afterwards “they pretended to be multiple relay groups without linking them directly together” [1].
KAX17: guards and middles at scale
KAX17, the name nusenu gave to a second actor, was active since at least 2017 and ran mainly guard and middle relays, peaking above 900 relays across more than 50 autonomous systems [2]. On 8 September 2020, nusenu estimated, its relays would have been chosen as guard with a probability of 10.34 per cent and as middle with 24.33 per cent [2]. The post is careful about what that shows: “We have no evidence, that they are actually performing de-anonymization attacks, but they are in a position to do so” [2]. The Tor Project later wrote that it had seen “dozens of relays” join “on 00:00:00 at the first of a month just to vanish slowly again”, and relays that “seemed to belong to a single operator” with no family declaration and an empty contact field, and that the group was removed after a tip at the end of October 2021 [4].
What already exists
The directory authorities assign flags in their votes. A relay is Valid if it runs “a version of Tor not known to be broken” and has not been blocklisted as suspicious; Stable if its weighted mean time between failures is at least the median or corresponds to at least 7 days; Guard if, among other conditions, it is Fast, Stable and “familiar”; and Exit only if it “allows exits to at least one /8 address space on each of ports 80 and 443” [7]. BadExit marks a relay “believed to be useless as an exit node” [8]. After a report, the Tor Project tries to fix the problem with the operator and otherwise applies BadExit, MiddleOnly or drops the relay from the consensus entirely [5]. A BadExit relay still serves in other positions [15].
Bandwidth is measured separately. The Simple Bandwidth Scanner (sbws) measures each relay through a two-hop circuit by downloading data from a web server, and produces a bandwidth file “read by a directory authority to report relays’ bandwidth in its vote” [9]. Onionoo, “a web-based protocol to learn about currently running Tor relays and bridges”, publishes for each relay its first_seen time (“when this relay was first seen in a network status consensus”), its autonomous system name, its advertised bandwidth, whether its weight is measured by three or more bandwidth authorities, its effective family, and a version_status such as “obsolete” [10]. Relay Search “displays data about single relays and bridges in the Tor Network” [11], and CollecTor archives descriptors “covering many years of Tor network history” [12].
Operators can prove who they are. The ContactInfo Information Sharing Specification lets a relay name a website and a proof; the url field “MUST point to a specific (non-shared) domain/hostname”, and tools “SHOULD re-verify the proof at least every 6 months” [13]. A companion draft calls the result an Authenticated Relay Operator ID (AROI), says that as of May 2023 over 65 per cent of exit capacity had adopted it, and describes its trust layer as, “To some extend … a reputation system” [14]. nusenu stresses the limit: “proven domains are not implicitly trusted, malicious groups can also proof their domain” [2].
Exits are also scanned. Winter et al. built exitmap, an active scanner, and HoneyConnector, which sends bait FTP and IMAP credentials and waits for their reuse; over months of monitoring they identified “65 exit relays that conducted MitM attacks or reused sniffed credentials” [6]. The Tor Project cites exitmap for its own automated checks [5]. The same paper states the asymmetry that limits every scanner: “an attacker is able to arbitrarily reduce the scope of the attack but we are unable to arbitrarily scale our scanner” [6].
| Mechanism | Run by | What it says about a relay | What it does not do |
|---|---|---|---|
| Directory authority flags (Valid, Stable, Guard, BadExit) | Directory authorities, by majority vote | Reachability, uptime and bandwidth thresholds; BadExit keeps clients from using it as an exit | No graded judgement: a flag is set or not |
| Bandwidth authorities (sbws) | Bandwidth scanners feeding the authorities | Measured capacity, used to weight path selection | Says nothing about honesty |
| Onionoo and Relay Search | Tor Metrics | First seen, AS name, family, version status, bandwidth | Describes; does not judge |
| CollecTor | Tor Metrics | Archived descriptors and consensuses | Raw data only |
| ContactInfo proof and AROI | Operators, opt-in | A verified domain for the operator | A proven domain is not proof of good intent |
| exitmap and bait credentials | Researchers and the Tor Project | Tampering seen during a probe; reuse of bait credentials | Misses targeted attacks and silent logging |
| Relay Authority (TorAi) | HisnLabs | One score from 0 to 100 per relay, with the reasons | List not published yet; not proof that a relay is honest |
The method under development
Relay Authority combines public signals into one number per relay, each with a stated reason. Age and stability come from first_seen and from the Stable and Guard flags [10] [7]. Bandwidth compares what a relay advertises with what the bandwidth authorities measure, since a relay that claims far more than it delivers is drawing traffic it cannot carry [10]. A verified operator and a declared family raise the score without settling it [13] [2]. Hygiene covers the tor version status [10] and the exit policy: an exit that opens port 80 but not 443 fails the Exit flag’s own definition [7], and the Tor Project’s older guidance flagged exits “Only allowing plain-text traffic” as “highly suspicious to be sniffing traffic” [15].
Network diversity counts because an organisation that controls or watches several autonomous systems or Internet exchange points can see both ends of more circuits; Johnson et al. found Tor users “far more susceptible to compromise than indicated by prior work” once such adversaries are modelled [16]. Suspicious waves are clusters of near-identical relays that appear together without a declared family, the pattern seen with both BTCMITM20 and KAX17 [1] [4]. Exit scan results and past offences complete the inputs, the latter because removed operators have returned within weeks [1]. The weights are not final and are not published here.
Two rules limit what the score may do. Only proven tampering or the BadExit flag lead to a hard ban; every other signal is a soft weight that makes a relay less likely to be chosen, never impossible, and path selection stays random. The reason is distinguishability. Danezis and Syverson show that route fingerprinting attacks “make use of what route creators do know of the network”, and note that concern about such partitioning “has deferred any deployment within Tor of a system that gives clients only a partial list of nodes” [17]. A client that excludes many relays narrows its choices and becomes easier to tell apart. For the same reason the list is designed to be signed, published once a day and downloaded whole, over Tor, by every copy of TorAi, so that all clients hold the same list and no lookup reveals which relay a user is about to use. There are no per-relay queries.
Two shortcuts are deliberately avoided. IP reputation and spam blocklists rate exits as abusive because every user’s traffic leaves from them; the Tor Project’s abuse templates begin, “The IP address in question is a Tor exit node”, and go on, “There is little we can do to trace this matter further” [19]. Such a list measures traffic, not tampering. Nor are large hosting companies penalised as such: the Tor Project asks new operators to avoid providers that “already attract a lot of Tor capacity” for diversity [18], and notes that many honest volunteers use the same cheap hosts, so that “when ten new relays show up, it's not straightforward to distinguish whether we just got ten new volunteers or one big one” [3]. Concentration lowers a weight; it does not mark a relay as malicious.
Implications for Tor users
The incidents show that bad relays are not rare accidents: the same operators returned after removal, and the Tor Project itself names two hard problems, that “Given an unknown relay, it's hard to know if it's malicious” and that it is hard to tell whether a group of relays is related [3]. A reputation score can lower the chance of using a relay that has shown warning signs. It cannot raise a relay above suspicion, and it does nothing against an exit that reads plaintext without changing it, since such a relay leaves no trace that any scanner, list or score can see. The protection against a reading exit remains encryption end to end.
Recommendations
- Use HTTPS everywhere you can, and onion services where a site offers one; a malicious exit cannot read or rewrite what it cannot decrypt.
- Treat Bitcoin addresses, download links and login pages reached over plain HTTP through Tor as untrusted.
- Report a relay you believe is tampering to bad-relays AT lists DOT torproject DOT org, with its fingerprint, what you saw and how to reproduce it.
- Do not hand-build long exclusion lists in your torrc; each excluded relay makes your client more distinctive.
- Read any relay score, including Relay Authority’s, as a weight with reasons, not as a verdict.
Relevance to TorAi
TorAi is a HisnLabs app for macOS; version 0.1.0, its first public release, is available and includes the client side of Relay Authority, but no list. Its page describes a live map that draws each routed app’s circuit, from the Mac to the guard, middle and exit relays, with relays placed by country, and a private record of bad exits kept on the Mac, in which proven tampering bans an exit and weak hints only warn [20]. Relay Authority is designed to add, for each relay on that map, its score, the date it was first seen, its country, its hosting company, its bandwidth and whether its operator is verified, together with the reasons for the score. The private record does not change: it stays on the Mac and is never shared. Relay Authority is a separate list computed from public Tor data and exit scan results, not from votes by users.
What TorAi does not do: it does not detect an exit that only reads traffic, it does not make an exit honest, it does not replace the Tor Project’s bad-relay process, and it does not look up relays one by one. The Relay Authority list is still being built. No list has been published and no results from HisnLabs runs are cited here; results will be published when the first public list is out. Details are on the TorAi page.
Limitations
A score built from public signals can be gamed slowly: an operator can run relays quietly for months, prove a domain and declare a family before acting, as the KAX17 and BTCMITM20 histories suggest [2] [1]. The reverse cost is real too: a new honest relay starts low, and the method has to let it rise without rewarding patience alone. Passive logging at an exit is invisible to everyone. The Spoiled Onions authors also note that attribution is hard, since tampering seen at an exit may come from its ISP or another network on the path [6]. The incident figures above are the sources’ own estimates and have not been reproduced by HisnLabs. Relay Authority is still being built, its weights may change, and HisnLabs makes TorAi, which readers should weigh. Further reading: the FireAI University lessons how Tor works and what it protects and VPNs, Tor and proxies, and the posts what Tor hides and what it does not, per-app Tor routing on macOS and onion services explained.
How FireAI and HisnLabs fit in
FireAI does not score Tor relays; it shows each connection your Mac’s apps make, including connections to Tor relays, and lets you decide which ones go through.
FireAI is HisnLabs’ own product: an on-device AI firewall for Mac. It shows every connection your apps make, in plain language, and lets you decide what leaves your Mac — its AI runs locally, so your traffic is never sent to us or anyone else. HisnLabs’ security research team is the group that keeps that decision-making accurate: cataloguing which domains are ordinary telemetry versus a real product, tracking the country and network behind a connection, and training the on-device model (its FireAI Pilot feature) on real traffic patterns, all without any of it leaving your Mac.
You can read the technical decisions behind it, or try FireAI for 17 days, at FireAI, by HisnLabs.