Dear relay operators, We've drafted a new proposal for the relay operator community.
The proposal introduces a lifecycle for Tor exit relays, inspired by the existing lifecycle used for Guard and HSDir flags. The main goal is to make it harder for attackers to quickly deploy malicious exit relays. Your feedback is welcome! You can read and comment on it here: https://gitlab.torproject.org/tpo/community/policies/-/issues/32. Alternatively, you can read the full text below. Gus ``` Filename: 102-tor-exit-lifecycle.md Title: Tor Exit lifecycle Author: Gus - gus at torproject.org, GeKo - gk at torproject.org, Hiro - hiro at torproject.org Created: 2025-10-14 Status: Draft ``` ## Overview Tor exit relays are maintained by volunteers and used to leave the Tor network and access websites and other online services. This proposal introduces a lifecycle for Tor exit relays, inspired by the lifecycle already used for non-exit relays to acquire particular flags, such as the Guard[1] and HSDir[2] flags. The main goal of this proposal is to make it harder for attackers to quickly deploy malicious exit relays and exploit Tor users. The proposed lifecycle adds a staging phase for new relays configured as exit relays. This is a period during which those relays are only functioning as non-exit relays. Afterwards, they become eligible for the Exit flag and can then be used as exit relays as intended. This exit relay lifecycle should raise the operational costs for malicious actors, enable earlier detection of bad relays[3], and provide more protection against Sybil attacks. ## Motivation Currently, because Tor is an open and public network, any relay operator can set up a new exit relay and, after a brief warm-up period, begin handling real user traffic. Malicious actors have exploited this openness to launch man-in-the-middle (MITM)[4][5] attacks, leading to a continuous "whack-a-mole" situation for the Network Health Team and the Directory Authorities: while attackers can often be blocked before causing major harm, significant human resources are required to keep up with them. As a small non-profit, it is essential for the Tor Project to focus its limited resources on mission-critical tasks. By implementing mitigations that force adversaries to invest more time and effort or make their attacks faster and easier to detect, we create a more favorable scenario for the Tor Project and its users. To help with that, a staged lifecycle for exit relays will: - Slow down the deployment speed of malicious exit relays as they will need to go through a staging phase. - Give time for analysis and automatic or proactive scanning before an exit relay sees and can exploit any outgoing user traffic. ## Proposal New relays configured as exit relays must complete a staging phase of 4 days (configurable) before becoming eligible for the Exit flag. The staging phase should be long enough to deter opportunistic abuse, but short enough not to discourage legitimate relay operators. ### Security implications The proposed change does not harm user anonymity or security. By reducing the number of new, untrusted exit relays on the Tor network, it improves safety for Tor users and disincentivizes short-lived "throwaway" malicious exit relays. ## Implementation considerations The exit relay lifecycle could be implemented with the help of Tor configuration options or consensus parameters, so that Directory Authorities can tune the staging length without a tor release, or disable the feature temporarily in unusual capacity situations. The exact code and format details will be specified in a follow-up torspec proposal (and then implemented in tor/arti). Note that the technical implementation may have slight changes to this proposal. ### Participation and Communication Once the exit lifecycle is implemented in a torspec proposal, a communication strategy will take place to inform and support relay operators. This strategy may include, but is not limited to, the following actions: - Update the [Tor Relay Operator documentation](https://community.torproject.org/relay) to include an explanation of the new exit relay lifecycle. - Display a banner on Tor Metrics Relay Search for new exit relays, directing users to the exit lifecycle proposal or relevant documentation. - Inform the relay operator community on their communication channels such as the tor-relays mailing list, blog post, and the Tor Forum. - Document new behavior resulted of the exit lifecycle, for example, if an exit relay drops of the consensus for a period, they will lose their exit flag and will need to restart the lifecycle described on this document. For the implementation discussion, see: https://gitlab.torproject.org/tpo/network-health/team/-/issues/220. ## Notes [1] Tor Guard specification: https://spec.torproject.org/guard-spec/index.html \ [2] HSDIR https://spec.torproject.org/tor-spec/subprotocol-versioning.html?highlight=hsdir#hsdir \ [3] Criteria for bad relays: https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Criteria-for-rejecting-bad-relays \ [4] Also known as a monster-in-the-middle, machine-in-the-middle, meddler-in-the-middle, manipulator-in-the-middle, person-in-the-middle (PITM), or adversary-in-the-middle (AITM) attack. \ [5] https://blog.torproject.org/bad-exit-relays-may-june-2020/ -- The Tor Project Community Team Lead
signature.asc
Description: PGP signature
_______________________________________________ tor-relays mailing list -- [email protected] To unsubscribe send an email to [email protected]
