Main menu

The New Guide to Running a Tor Relay

Have we told you lately how much we love our relay operators? Relays are the backbone of the Tor network, providing strength and bandwidth for our millions of users worldwide. Without the thousands of fast, reliable relays in the network, Tor wouldn't exist.

Have you considered running a relay, but didn't know where to start? Perhaps you're just looking for a way to help Tor, but you've always thought that running a relay was too complicated or technical for you and the documentation seemed daunting.

We're here to tell you that you can become one of the many thousands of relay operators powering the Tor network, if you have some basic command-line experience.

We've made the guide read-only in order to maintain quality control over the content. This guide updates and replaces existing relay documentation. Eventually, the Tor Relay Guide will become part of our future Community Portal, which will live at community.torproject.org (not available yet). In addition to the Tor Relay Guide content, the Community Portal will include information for Tor trainers, ways to get involved with the Tor community, talks and other events happening in the Tor world, and more.

If you run into technical issues while setting up your relay, please reach out to the tor-relays mailing list (subscribing is required to post to the list).

Did you find a mistake or want to help improving the guide? Let us know. Please file your suggestions on trac.torproject.org under the "Community/Relays" component.

It's a hobby/c.v. tag : usa old_U style.
Running a relay with the support of an organization/firm/asso/school could be an option, a challenge ; alone it should be a suicide, a waste of time & money.
This article asks participation & effort from "users" or from a politic/social class who could change an influence. They have failed definitively _netneutrality,freedom of speech,etc._ in the usa (canada-australia-newzealand-uk). I think that they should begin to work from NYC to the others towns of the united states and build their own network for their private resident first (melting-pot) : the usa is a materialist world not an idealist one (incompatibility).

The guide is awesome, and addresses the issues raised many times here (e.g. give us a sense of the minimum useful bw needed for non-exit node) which were not IMO clearly addressed in previous guides. Also very happy to see good advice regarding improving geolocation diversity. Thank you much!

Please try to make sure this guide is very easy to find in the torproject.org homepage and that the permalink can be easily cited. (Having at trac.torproject.org seems a bit awkward, but if there is a good reason for that, I can live with it.)

Quick question:

> Any modern CPU should be fine.

Do the Meltdown/Spectre vulnerabilities pose a potential threat to Tor nodes? According to what I've read at wired.com etc, these break the low-level distinction between kernel space memory and user space memory, potentially allowing unprivileged process to directly access cryptographic keys etc held in kernel space memory. If I understand correctly, this could enable a determined attacker to read Tor traffic if they compromise enough nodes.

Further, I understand that known forensic methods are unlikely to be able to detect that information has been accessed in this way.

Further, I understand that the Intel patches which prevent speculative execution can slow down performance by 30% in such areas as cryptographic processing and data transfers over internet, which would appear to affect Tor nodes. It appears possible that some software which expects computations to be completed quickly might break due to the slowdown. I guess that most tor servers should handle an unexpected 30% slowdown, but has anyone checked?

Many thanks to the authors of the new Guide! It clearly addresses many of the basic issues which were not clearly addressed by previous guides (e.g. minimal useful bandwidth, how to increase geolocational diversity).

Can TP please ensure that this new guide remains easy to find/cite? The URL should be put high on the landing page, I think.

Also, thanks to nusenu for diligently searching for undeclared families which might be doing something bad (e.g. attacking the Tor network as per Carnegie-Mellon/FBI). That is a very important but tricky task.

> The head of the FBI is expected to appear before the Senate Intelligence Committee in the coming week for a routine hearing about global threats that pose a risk to U.S. national security.

So FBI Director Wray will be there--- will Tor Project be there to defend Tor users against FBI's latest "Going Dark" demands? Cannot TP leverage its former status as a product of USG to garner a little face time before Congress, in order to present our POV?

Director Wray is likely to blame Tor for the Dec 2015 cyberattack which brought down portions of the Ukraine power grid, and to use this to argue for making strong encryption (and thus, Tor and Wikipedia) illegal. It is relevant that the US House just passed a bill funding cybersecurity cooperation between USA and Ukraine, precisely to counter the threat of cyberattacks to power grids, including those using "smart meters" which are far more vulnerable (much higher attack profile).

We need Tor Project to try to make sure that Congress understands what Tor really does and how it works. We need to make sure Congress understands that Tor is not part of the problem but rather part of the solution. If we fail to do so, we may wake up to find our doors being kicked in because we are using something we need which has been declared in dead of night to be "illegal encryption".

Neither Wray nor longtime anti-encryption hawk Manhattan DA Cy Vance (son of the former Secretary of State) are likely to mention the fact in their testimony the fact that NYPD has issued encrypted-by-default "smart phones" (iPhone 7) to its officers:

techdirt.com
Will Cy Vance's Anti-Encryption Pitch Change Now That The NYPD's Using iPhones?
from the or-will-encryption-only-be-an-option-for-the-protected-class? dept
12 Feb 2018

It seems noteworthy that two outstanding civil rights figures have died: John Perry Barlow, author of the Internet Manifesto and founder of EFF, and Asma Jahangir, who fearlessly challenged the worse abuses of the PK government (unfortunately, disappearances of students and bloggers in PK is again rising).

So if USG declares unbackdoored encryption illegal, what is our plan? Will TP renege on its vow never to introduce backdoors into Tor? Will TP be able to immediately move overseas and to continue to provide Tor to USPERs? Are TP people prepared to go underground, or will key Tor People employees quit? Or will TP simply shut down?

I hate the first and last options. Perhaps if we had an honest public discussion we could find better options.

Teresa May is moving down a list, attacking successively smaller messaging platforms. When will she come to Tor Project?

theguardian.com
May calls again for tech firms to act on encrypted messaging
Focus shifts to smaller platforms that can ‘quickly become home to criminals and terrorists’
Alex Hern
25 Jan 2018

> “These companies simply cannot stand by while their platforms are used to facilitate child abuse, modern slavery or the spreading of terrorist and extremist content,” she told the audience in Davos. ... “Just as these big companies need to step up, so we also need cross-industry responses because smaller platforms can quickly become home to criminals and terrorists. We have seen that happen with Telegram. And we need to see more cooperation from smaller platforms like this,” she said.

> Despite the years of strong words, however, actions from the UK government have been rare. The Investigatory Powers Act of 2016, strongly backed by May while she was home secretary, gave the government the power to demand the removal of encryption applied to messages, but the government has yet to apply that power to any major technology firm.

TP is neither "major" nor a "firm". Nor well-funded. Is TP ready for a removal order issued by the UK government? What is the plan if you are served with one?

Recent Updates

There's a new alpha release available for download. If you build Tor from source, you can download the source code for 0.4.0.1-alpha from the usual place on the website. Packages should be available over the coming weeks, with a new alpha Tor Browser release likely by the end of the month.

Remember, this is an alpha release: you should only run this if you'd like to find and report more bugs than usual.

Tor 0.4.0.1-alpha is the first release in the new 0.4.0.x series. It introduces improved features for power and bandwidth conservation, more accurate reporting of bootstrap progress for user interfaces, and an experimental backend for an exciting new adaptive padding feature. There is also the usual assortment of bugfixes and minor features, all described below.

Changes in version 0.4.0.1-alpha - 2019-01-18

Major features (battery management, client, dormant mode):

When Tor is running as a client, and it is unused for a long time, it can now enter a "dormant" state. When Tor is dormant, it avoids network and CPU activity until it is reawoken either by a user request or by a controller command. For more information, see the configuration options starting with "Dormant". Implements tickets 2149 and 28335.

The client's memory of whether it is "dormant", and how long it has spent idle, persists across invocations. Implements ticket 28624.

There is a DormantOnFirstStartup option that integrators can use if they expect that in many cases, Tor will be installed but not used.

Major features (bootstrap reporting):

When reporting bootstrap progress, report the first connection uniformly, regardless of whether it's a connection for building application circuits. This allows finer-grained reporting of early progress than previously possible, with the improvements of ticket 27169. Closes tickets 27167 and 27103. Addresses ticket 27308.

When reporting bootstrap progress, treat connecting to a proxy or pluggable transport as separate from having successfully used that proxy or pluggable transport to connect to a relay. Closes tickets 27100 and 28884.

Tor 0.3.5.7 is the first stable release in its series; it includes compilation and portability fixes, and a fix for a severe problem affecting directory caches. Tor 0.3.4.10 and 0.3.3.11 are also released today; please see the official announcements for those releases if you are tracking older stable versions.

The Tor 0.3.5 series includes several new features and performance improvements, including client authorization for v3 onion services, cleanups to bootstrap reporting, support for improved bandwidth- measurement tools, experimental support for NSS in place of OpenSSL, and much more. It also begins a full reorganization of Tor's code layout, for improved modularity and maintainability in the future. Finally, there is the usual set of performance improvements and bugfixes that we try to do in every release series.

There are a couple of changes in the 0.3.5 that may affect compatibility. First, the default version for newly created onion services is now v3. Use the HiddenServiceVersion option if you want to override this. Second, some log messages related to bootstrapping have changed; if you use stem, you may need to update to the latest version so it will recognize them.

We have designated 0.3.5 as a "long-term support" (LTS) series: we will continue to patch major bugs in typical configurations of 0.3.5 until at least 1 Feb 2022. (We do not plan to provide long-term support for embedding, Rust support, NSS support, running a directory authority, or unsupported platforms. For these, you will need to stick with the latest stable release.)

Below are the changes since 0.3.5.6-rc. For a complete list of changes since 0.3.4.9, see the ReleaseNotes file.

Changes in version 0.3.5.7 - 2019-01-07

Major bugfixes (relay, directory):

Always reactivate linked connections in the main loop so long as any linked connection has been active. Previously, connections serving directory information wouldn't get reactivated after the first chunk of data was sent (usually 32KB), which would prevent clients from bootstrapping. Fixes bug 28912; bugfix on 0.3.4.1-alpha. Patch by "cypherpunks3".