How Tor Directory Authorities Add New Relays

When a new Tor relay joins the network, it must be discovered, verified, and officially listed before it can route user traffic. This process involves the relay performing self-reachability tests, publishing a cryptographic descriptor, and submitting it to a trusted group of servers known as Directory Authorities (DirAuths). These authorities independently verify the relay’s availability, vote on its status, and publish an hourly network consensus document that Tor clients use to build circuits.

1. Relay Initialization and Self-Testing

Before contacting the network, a newly configured relay generates its long-term identity keys and onion keys. It then attempts a self-test by opening connections to its own configured Onion Router Port (ORPort) and Directory Port (DirPort). The relay will not attempt to register with the network until it confirms that its ports are publicly reachable from the outside internet.

2. Descriptor Generation and Upload

Once reachability is self-confirmed, the relay builds a signed document called a “server descriptor.” This document contains essential metadata, including: * Public encryption and identity keys * IP address and port numbers * Bandwidth capacity declarations * Exit policies (defining what outbound traffic the relay permits)

The relay automatically uploads this signed descriptor via HTTP/HTTPS to the hardcoded list of Tor Directory Authorities.

3. Authority Verification and Probing

Upon receiving the descriptor, each Directory Authority independently tests the new relay to confirm it is not spoofed or offline. An authority attempts to establish an encrypted TLS connection to the relay’s ORPort.

If the connection succeeds and the cryptographic identity matches the descriptor, the authority marks the relay as reachable and valid. If the probe fails, the authority drops the descriptor and will not vote to include the relay.

4. Hourly Voting Process

Directory Authorities do not maintain a single static database; instead, they operate on a decentralized voting cycle once every hour.

During the voting phase: 1. Each authority compiles a list of all relays it believes are currently running and reachable. 2. The authority assigns status flags to the relays (such as Running, Valid, Fast, Guard, or Exit). 3. The authorities exchange their individual vote documents with one another.

5. Consensus Compilation

After exchanging votes, the Directory Authorities compute a single deterministic document called the “network consensus.” A relay is included in the consensus only if a majority of the authorities agree that the relay is valid and online. The consensus establishes the official network state, including the relay’s assigned bandwidth weight and trust flags.

6. Client Retrieval and Lifecycle

Once a majority of authorities sign the consensus document, it is published across the network and mirrored by directory caches. Tor clients download the updated consensus during their regular polling cycles.

A newly added relay begins with low traffic allocation. Bandwidth authorities continuously measure its performance over several days or weeks, gradually ramping up its consensus weight as it demonstrates sustained reliability and uptime.