Lifecycle of a Tor exit

Filename: 102-lifecycle-of-a-tor-exit.md
Title: Lifecycle of a Tor exit
Author: Gus - gus at torproject.org, GeKo - gk at torproject.org, Hiro - hiro at torproject.org
Created: 2026-01-12
Status: Accepted

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 lifecycle of a Tor exit 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 relays and attacks better to detect or prevent, 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 reduces the number of available exit relays for the time of the staging phase. Moreover, it might discourage operators from running exit relays to begin with because nobody is using their newly added exit relays during that phase and, depending on how we implement this feature, those relays might get flagged surprisingly. Neither of those issues is problematic. First of all, we have plenty of already existing exit relays and a short staging phase should not impact exit relay and operator diversity much, in particular under the assumption that we are not getting flooded with dozens of new exit relays anyway as that would be treated as a Sybil attack. Secondly, we can avoid any relevant discouragement by explaining the feature properly using our communication strategy, which is outlined below. Overall, by reducing the number of new, untrusted exit relays on the Tor network, we improve the safety for Tor users and disincentivize short-lived "throwaway" malicious exit relays, which is a net benefit.

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 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/