gitlab.torproject.org
Open in
urlscan Pro
2a01:4f8:fff0:4f:266:37ff:feb8:3489
Public Scan
Submitted URL: https://trac.torproject.org/projects/tor/wiki/TorRelayGuide
Effective URL: https://gitlab.torproject.org/legacy/trac/-/wikis/TorRelayGuide
Submission: On August 30 via api from US — Scanned from DE
Effective URL: https://gitlab.torproject.org/legacy/trac/-/wikis/TorRelayGuide
Submission: On August 30 via api from US — Scanned from DE
Form analysis 0 forms found in the DOM
Text Content
Skip to content
GitLab
* Erkunden
* Anmelden
PRIMÄRNAVIGATION
Suchen oder aufrufen …
Projekt
* Trac
* Verwalten
* Aktivität
* Mitglieder
* Labels
* Planen
* Tickets
246
* Ticketübersichten
* Meilensteine
* Wiki
* Bereitstellung
* Container-Registry
* Überwachen
* Vorfälle
* Service-Desk
* Analysieren
* Wertschöpfungskettenanalyse
Hilfe
* * Hilfe
* Support
* GitLab-Dokumentation
* GitLab-Pläne vergleichen
* Community-Forum
* Zu GitLab beitragen
* Feedback geben
* * Tastenkürzel ?
Code-Schnipsel Gruppen Projekte
Archiviertes Projekt. Repository und andere Projektressourcen sind
schreibgeschützt
1. Legacy
2. Trac
3. Wiki
4. TorRelayGuide
TORRELAYGUIDE
Neue Seite Vorlagen
Repository klonen
* Seitenverlauf
Last edited by Alexander Færøy vor 4 Jahren
= The Tor Relay Guide moved to https://community.torproject.org/relay/ =
THE CONTENT ON THIS PAGE IS NO LONGER MAINTAINED.
== Using this guide == This guide includes the best practices that are essential
for healthy Tor relays. We've included technical steps, legal considerations,
and information about running relays with others. It's organized into three
parts:
* TorRelayGuide#Partone:decidingtorunarelay
* TorRelayGuide#Parttwo:technicalsetup
* TorRelayGuide#Partthree:legalinfosocialinfoandmoreresources
If you wish to skip directly to setting up a relay, read part two only.
==== Usage of "Tor" and "tor" in this guide
We use "tor" (lower case) whenever we talk specifically about the program tor
(the daemon), in all other cases we use "Tor".
== Part one: deciding to run a relay ==
WHY RUN A TOR RELAY?
By running a Tor relay you can help make the Tor network:
* faster (and therefore more usable)
* more robust against attacks
* more stable in case of outages
* safer for its users (spying on more relays is harder than on a few)
=== Types of nodes in the Tor network ===
All nodes are important, but they have different technical requirements and
legal implications. Understanding the different kinds of nodes is the first step
to learning which one is right for you.
==== Guard/middle (aka non-exit) relay
A guard is the first relay in the chain of 3 relays building a Tor circuit. A
middle relay is neither a guard nor an exit, but acts as the second hop between
the two. To become a guard, a relay has to be stable and fast (at least
2MByte/s) otherwise it will remain a middle relay.
Guard and middle relays usually do not receive abuse complaints. All relays will
be listed in the public list of Tor relays, so may be blocked by certain
services that don't understand how Tor works or deliberately want to censor Tor
users. If you are running a relay from home and have one static IP, you may want
to consider running a bridge instead so that your non-Tor traffic doesn't get
blocked as though it's coming from Tor. If you have a dynamic IP address or
multiple static IPs, this isn't as much of an issue.
A non-exit Tor relay requires minimal maintenance efforts and bandwidth usage
can be highly customized in the tor configuration (will be covered in more
detail later in this guide). The so called "exit policy" of the relay decides if
it is a relay allowing clients to exit or not. A non-exit relay does not allow
exiting in its exit policy.
EXIT RELAY
The exit relay is the final relay in a Tor circuit, the one that sends traffic
out its destination. The services Tor clients are connecting to (website, chat
service, email provider, etc) will see the IP address of the exit relay instead
of their real IP address of the Tor user.
Exit relays have the greatest legal exposure and liability of all the relays.
For example, if a user downloads copyrighted material while using your exit
relay, you the operator may receive a DMCA notice. Any abuse complaints about
the exit will go directly to you (via your hoster, depending on the WHOIS
records). Generally, most complaints can be handled pretty easily through
template letters, which we'll discuss more in legal considerations section.
Because of the legal exposure that comes with running an exit relay, you should
not run a Tor exit relay from your home. Ideal exit relay operators are
affiliated with some institution, like a university, a library, a hackerspace or
a privacy related organization. An institution can not only provide greater
bandwidth for the exit, but is better positioned to handle abuse complaints or
the rare law enforcement inquiry.
If you are considering running an exit relay, please read
TorRelayGuide#Legalconsiderationsforexitrelayoperators for exit relay operators.
BRIDGE
The design of the Tor network means that the IP address of Tor relays is public.
However, one of the ways Tor can be blocked by governments or ISPs is by
blacklisting the IP addresses of these public Tor nodes. Tor bridges are nodes
in the network that are not listed in the public Tor directory, which make it
harder for ISPs and governments to block them.
Bridges are useful for Tor users under oppressive regimes or for people who want
an extra layer of security because they're worried somebody will recognize that
they are contacting a public Tor relay IP address. Several countries, including
China and Iran, have found ways to detect and block connections to Tor bridges.
Pluggable transports
(https://www.torproject.org/docs/pluggable-transports.html.en), a special kind
of bridge, address this by adding an additional layer of obfuscation.
Bridges are relatively easy, low-risk and low bandwidth Tor nodes to operate,
but they have a big impact on users. A bridge isn't likely to receive any abuse
complaints, and since bridges are not listed in the public consensus, they are
unlikely to be blocked by popular services. Bridges are a great option if you
can only run a Tor node from your home network, have only one static IP, and
don't have a huge amount of bandwidth to donate -- we recommend giving your
bridge at least 1 Mbit/sec.
RELAY REQUIREMENTS
Requirements for Tor relays depend on the type of relay and the bandwidth they
provide.
==== Bandwidth and Connections
* A non-exit relay should be able to handle at least 7000 concurrent
connections. This can overwhelm consumer-level routers. If you run the Tor
relay from a server (virtual or dedicated) in a data center you will be fine.
If you run it behind a consumer-level router at home you will have to try and
see if your home router can handle it or if it starts failing. Fast exit
relays (>=100 Mbit/s) usually have to handle a lot more concurrent
connections (>100k).
* It is recommended that a relay have at least 16 Mbit/s (Mbps) upload
bandwidth and 16 Mbit/s (Mbps) download bandwidth available for Tor. More is
better. The minimum requirements for a relay are 10 Mbit/s (Mbps). If you
have less than 10 Mbit/s but at least 1 Mbit/s we recommend you run a
[/wiki/doc/PluggableTransports/obfs4proxy bridge with obfs4 support]. If you
do not know your bandwidth you can use http://beta.speedtest.net to measure
it.
Monthly Outbound Traffic
* It is required that a Tor relay be allowed to use a minimum of 100 GByte of
outbound traffic (and the same amount of incoming traffic) per month. Note:
That is only about 1 day worth of traffic on a 10 Mbit/s (Mbps) connection.
More (>2 TB/month) is better and recommended. Ideally a relay runs on
unmetered plan. If you have a metered plan you might want to
TorRelayGuide#Limitingbandwidthusageandtraffic.
==== Public IPv4 Address Every relay needs a public IPv4 address - either
directly on the host (preferred) or via NAT and port forwarding.
The IPv4 address is not required to be static but static IP addresses are
preferred. Your IPv4 address should remain unchanged for at least 3 hours (if it
regularly changes more often than that, it does not make much sense to run a
relay or bridge there since it takes time to distribute the new list of relay
IPs to clients - which happens only once every hour).
Additional IPv6 connectivity is great and recommended/encouraged but not a
requirement. There should be no problem at all with this requirement (all
commercially available servers come with at least one IPv4 address).
Note: You can only run two Tor relays per public IPv4 address. If you want to
run more than two relays you will need more IPv4 addresses.
==== Memory Requirements
* A <40 Mbit/s non-exit relay should have at least 512 MB of RAM available.
* A non-exit relay faster than 40 Mbit/s should have at least 1 GB of RAM.
* On an exit relay we recommend at least 1.5 GB of RAM per tor instance.
==== Disk Storage
Tor does not need much disk storage. A typical Tor relay needs less than 200 MB
for Tor related data.
==== CPU
* Any modern CPU should be fine.
* It is recommended to use CPUs with AESNI support (that will improve
performance and allow for up to about ~400-450 Mbps in each direction on a
single tor instance on modern CPUs). If the file /proc/cpuinfo contains the
word aes your CPU has support for AES-NI.
==== Uptime
* Tor has no hard uptime requirement but if your relay is not running for more
than 2 hours a day its usefulness is limited. Ideally the relay runs on a
server which runs 24/7. Reboots and tor daemon restarts are fine.
==== Tor Version
For security reasons, Tor relays should not downgrade their tor version from a
org/teams/NetworkTeam/CoreTorReleases#Listofreleases to an unsupported version
of tor. Some unsupported versions are insecure. Relays that attempt to downgrade
to an insecure version will be rejected from the network automatically.
== Part two: technical setup
=== Considerations when choosing a hosting provider
If you have access to a high speed internet connection (>=100 Mbit/s in both
directions) and a physical piece of computer hardware, this is the best way to
run a relay. Having full control over the hardware and connection gives you a
more controllable and (if done correctly) secure environment. You can host your
own physical hardware at home (do NOT run a Tor exit relay from your home) or in
a data center. Sometimes this is referred to as installing the relay on "bare
metal".
If you do not own physical hardware, you could run a relay on a rented dedicated
server or virtual private server (VPS). This can cost anywhere between
$3.00/month and thousands per month, depending on your provider, hardware
configuration, and bandwidth usage. Many VPS providers will not allow you to run
exit relays. You must follow the VPS provider's terms of service, or risk having
your account disabled. For more information on hosting providers and their
policies on allowing Tor relays, please see this list maintained by the Tor
community: [/wiki/doc/GoodBadISPs GoodBadISPs].
==== Questions to consider when choosing a hoster
* How much monthly traffic is included? (Is bandwidth "unmetered"?)
* Does the hoster provide IPv6 connectivity? (it is recommended, but not
required)
* What virtualization / hypervisor (if any) does the provider use? (anything
but OpenVZ should be fine)
* Does the hoster start to throttle bandwidth after a certain amount of
traffic?
* How well connected is the autonomous system of the hoster? To answer this
question you can use the AS rank of the autonomous systems if you want to
compare: http://as-rank.caida.org/ (a lower value is better).
==== If you plan to run Exit Relays:
* Does the hoster allow Tor exit relays? (explicitly ask them before starting
an exit relay there)
* Does the hoster allow custom WHOIS records for your IP addresses? This helps
reduce the amount of abuse sent to the hoster instead of you.
* Does the hoster allow you to set a custom DNS reverse entry? (DNS PTR record)
This are probably things you will need to ask the hoster in a Pre-Sales
ticket.
==== AS/location diversity
When selecting your hosting provider, consider network diversity on an
autonomous system (AS) and country level. A more diverse network is more
resilient to attacks and outages. Sometimes it is not clear which AS you are
buying from in case of resellers. To be sure it is best to ask the hoster about
the AS number before ordering a server.
It is best to avoid hosters where many Tor relays are already hosted, but it is
still better to add one there than to run no relay at all. Try to avoid the
following hoster:
* OVH SAS (AS16276)
* Online S.a.s. (AS12876)
* Hetzner Online GmbH (AS24940)
* DigitalOcean, LLC (AS14061)
To find out which hoster and countries are already used by many other operators
(that should be avoided) you can use Relay Search:
* Autonomous System Level Overview
* https://metrics.torproject.org/rs.html#aggregate/as
* Country Level Overview
* https://metrics.torproject.org/rs.html#aggregate/cc
==== Choosing an Operating System
We recommend you use the operating system you are most familiar with. Please
keep in mind that since most relays run on Debian and we want to avoid a
monoculture, *BSD based relays are greatly needed.
The following table shows the current OS distribution on the Tor network to give
you an idea of how much more non-Linux relays we should have:
* https://nusenu.github.io/OrNetStats/#os-distribution-relays
=== OS Level Configuration
OS configuration is outside the scope of this guide but the following points are
crucial for a Tor relay, so we want to mention them here nonetheless.
==== Time Synchronization (NTP)
Correct time settings are essential for Tor relays. It is recommended that you
use the network time protocol (NTP) for time synchronization and ensure your
timezone is set correctly.
==== Automatic Software Updates
One of the most imported things to keeps your relay secure is to install
security updates timely and ideally automatically so you can not forget about
it. We collected the steps to enable automatic software updates for different
operating systems:
* TorRelayGuide/RPMUpdates (RHEL, CentOS, Fedora, openSUSE)
* TorRelayGuide/DebianUbuntuUpdates
* TorRelayGuide/BSDUpdates
TOR RELAY SETUP: INSTALLATION AND CONFIGURATION
This section covers the installation and configuration of the program required
to run a Tor relay for various operating systems. These steps are intended for
the latest stable version of the given OS, on Ubuntu for the latest LTS release.
Note: For some operating systems, there are alpha version packages available
(tor versions with new features not deemed to be stable yet). These are only
recommended for people eager to test and report bugs in bleeding edge
releases/features. If you are looking to run a relay with minimal effort we
recommend you stick to stable releases.
In this guide we describe how to setup a new non-exit relay. By reading further
you can easily switch to become an exit relay.
Questions you should clarify before configuring Tor:
* Do you want to run a Tor exit or non-exit (guard/middle) relay?
* If you want to run an exit relay: Which ports do you want to allow in your
exit policy? (more ports usually means potentially more abuse complains)
* What external TCP port do you want to use for incoming Tor connections?
("ORPort" configuration, we recommend port 443 if that is not used by another
daemon on your server already. ORPort 443 is recommended because it is often
one of the few open ports on public WIFI networks. Port 9001 is another
commonly used ORPort.)
* What email address will you use in the ContactInfo field of your relay(s)?
Note: This information will be made public.
* How much bandwidth/monthly traffic do you want to allow for Tor traffic?
* Does the server have an IPv6 address?
The installation commands are shown in code blocks and must be executed with
root privileges.
==== Make sure relay ports can be reached
If you are using a firewall, open a hole in your firewall so incoming
connections can reach the ports you will use for your relay (ORPort, plus
DirPort if you enabled it). Also, make sure you allow all outgoing connections
too, so your relay can reach the other Tor relays, clients and destinations. You
can find the specific ORPort TCP port number in the torrc configuration samples
bellow (in the OS specific sections).
==== Configuration Management
Tor does not scale well on multi-core machines. If you run a Tor relay on a
server with a fast Internet uplink (>200 Mbit/s) you might want to consider
running multiple Tor instances on a single server with multiple cores. Note: You
can only run two tor instances per public IPv4 address.
If you plan to run more than a single relay, or you want to run a high capacity
relay (multiple Tor instances per server) or want to use strong security
features like [/wiki/doc/TorRelaySecurity/OfflineKeys Offline Master Keys]
without performing additional steps manually, you may want to use a
configuration management for better maintainability.
There are multiple configuration management solutions for Unix based operating
systems (Ansible, Puppet, Salt, ...).
The following Ansible Role has specifically been build for Tor relay operators
and supports multiple operating systems:
* http://github.com/nusenu/ansible-relayor
The following bash script for Debian and Ubuntu is not a configuration
management but can also help you automate the steps to setup a new single Tor
relay. It is meant to be run on a server that is only used for Tor.
* https://github.com/coldhakca/tor-relay-bootstrap
==== Platform specific Instructions
Please choose your platform:
* TorRelayGuide/DebianUbuntu
* TorRelayGuide/CentOSRHEL
* TorRelayGuide/Fedora
* TorRelayGuide/FreeBSD
* TorRelayGuide/openSUSE
=== Verify that your relay works If your logfile (syslog) contains the following
entry after starting your tor daemon your relay should be up and running as
expected:
Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
About 3 hours after you started your relay it should appear on Relay Search
(https://metrics.torproject.org/rs.html). You can search for your relay using
your nickname or IP address.
=== Getting Help
If you run into problems while setting up your relay you can ask your questions
on the public tor-relays mailing list:
* https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays This is a
great resource for asking (and answering) questions, and generally getting to
know other relay operators. Make sure to check out the archives!
=== Limiting bandwidth usage (and traffic) Tor will not limit its bandwidth
usage by default, but supports multiple ways to restrict the used bandwidth and
the amount of traffic. This can be handy if you want to ensure that your Tor
relay does not exceed a certain amount of bandwidth or total traffic per
day/week/month. The following torrc configuration options can be used to
restrict bandwidth and traffic:
* AccountingMax
* AccountingRule
* AccountingStart
* BandwidthRate
* BandwidthBurst
* RelayBandwidthRate
Having a fast relay for some time of the month is preferred over a slow relay
for the entire month.
Also see the bandwidth entry in the FAQ:
https://www.torproject.org/docs/faq.html.en#BandwidthShaping
=== IPv6
We encourage everyone to enable IPv6 on their relays. This is especially
valuable on exit and guard relays.
Before enabling your tor daemon to use IPv6 in addition to IPv4 you should do
some basic IPv6 connectivity tests.
The following command line will ping the IPv6 addresses of Tor directory
authorities from your server:
ping6 -c2 2001:858:2:2:aabb:0:563b:1526 && ping6 -c2 2620:13:4000:6000::1000:118 && ping6 -c2 2001:67c:289c::9 && ping6 -c2 2001:678:558:1000::244 && ping6 -c2 2607:8500:154::3 && ping6 -c2 2001:638:a000:4140::ffff:189 && echo OK.
At the end of the output you should see "OK." if that is not the case do not
enable IPv6 in your torrc configuration file before IPv6 is indeed working. If
you enable IPv6 without working IPv6 connectivity your entire relay will not be
used, regardless if IPv4 is working.
If it worked fine, make your Tor relay reachable via IPv6 by adding an
additional ORPort line to your configuration (example for ORPort 9001):
ORPort [IPv6-address]:9001
The location of that line in the configuration file does not matter you can
simply add it next to the first ORPort lins in your torrc file.
Note: You have to explicitly specify your IPv6 address in square brackets, you
can not tell tor to bind to any IPv6 (like you do for IPv4). If you have a
global IPv6 address you should be able to find it in the output of the following
command:
ip addr|grep inet6|grep global
If you are an exit relay with IPv6 connectivity, tell your tor daemon to allow
exiting via IPv6 so clients can reach IPv6 destinations:
IPv6Exit 1
Note: Tor requires IPv4 connectivity, you can not run a Tor relay on IPv6-only.
Additional information related to IPv6 can be found in the
[/wiki/doc/IPv6RelayHowto IPv6RelayHowto].
=== Important if you run more than one Tor instance
To avoid putting Tor clients at risk when operating multiple relays you must set
a proper MyFamily value and have a valid ContactInfo in your torrc
configuration. The MyFamily setting is simply telling Tor clients what Tor
relays are controlled by a single entity/operator/organization, so they don't
use them in multiple position in a single circuit.
If you run two relays and they have fingerprints AAAAAAAAAA and BBBBBBBB, you
would add the following configuration to set MyFamily:
MyFamily AAAAAAAAAA,BBBBBBBB
to both relays. To find your relays fingerprint you can look into the log files
when tor starts up or find the file named "fingerprint" in your tor
DataDirectory.
Instead of doing so manually for big operators we recommend to automate the
MyFamily setting via a TorRelayGuide#ConfigurationManagement. Manually managing
MyFamily for big relaygroups is error prone and can put Tor clients at risk.
=== Exit Relay Configuration
It is recommended that you setup exit relays on servers dedicated to this
purpose. It is not recommended to install Tor exit relays on servers that you
need for other services as well. Do not mix your own traffic with your exit
relay traffic.
==== Reverse DNS and WHOIS record
Before switching your relay to become an exit relay, ensure that you have set a
clear DNS reverse (PTR) record to make it clear for everyone that this is a tor
exit relay. Something like "tor-exit" it its name is a good start.
If your provider offers it, make sure your WHOIS record contains clear
indications that this is a Tor exit relay.
==== Exit Notice HTML page
To make it even more obvious that this is a Tor exit relay you should serve a
Tor exit notice HTML page. Tor can do that for you if your DirPort is on TCP
port 80, you can make use of tor's DirPortFrontPage feature to display a HTML
file on that port. This file will be shown to anyone directing his browser to
your Tor exit relay IP address.
DirPort 80
DirPortFrontPage /path/to/html/file
We offer a sample Tor exit notice HTML file, but you might want to adjust it to
your needs:
https://gitweb.torproject.org/tor.git/plain/contrib/operator-tools/tor-exit-notice.html
Here are some more tips for running a reliable exit relay:
https://blog.torproject.org/tips-running-exit-node
==== DNS on Exit Relays
Unlike other types of relays, exit relays also do DNS resolution for Tor
clients. DNS resolution on exit relays is crucial for Tor clients, it should be
reliable and fast by using caching.
* DNS resolution can have a significant impact on the performance and
reliability your exit relay provides. Poor DNS performance will result in
less traffic going through your exit relay.
* Don't use any of the big DNS resolvers as your primary or fallback DNS
resolver to avoid centralization (Google, OpenDNS, Quad9, Cloudflare,
4.2.2.1-6)
* We recommend running a local caching and DNSSEC-validating resolver without
using any forwarders (specific instructions follow bellow for each operating
systems)
* if you want to add a second DNS resolver as a fallback to your
/etc/resolv.conf configuration, try to choose a resolver within your
autonomous system and make sure it is not your first entry in that file (the
first entry should be your local resolver)
* if a local resolver like unbound is not an option for you try to use a
resolver that your provider runs in the same autonomous system (to find out
if an IP address is in the same AS as your relay, you can look it up, using
for example https://bgp.he.net).
* try to avoid adding too many resolvers to your /etc/resolv.conf file to limit
exposure on an AS-level (try to not use more than two entries)
There are multiple options for DNS server software, unbound has become a popular
one but feel free to use any other you are comfortable with. When choosing your
DNS resolver software try to ensure it supports DNSSEC validation and QNAME
minimisation (RFC7816). In every case the software should be installed using the
OS package manager to ensure it is updated with the rest of the system.
By using your own DNS resolver you are less vulnerable to DNS-based censorship
that your upstream resolver might impose.
Here follow specific instructions on how to install and configure unbound on
your exit - a DNSSEC-validating and caching resolver. unbound has many
configuration and tuning nobs but we try to keep these instructions as simple
and short as possible and the basic setup will do just fine for most operators.
After switching to unbound verify it works as expected by resolving a valid
hostname, if it does not work, you can restore the old resolv.conf file.
===== Debian/Ubuntu
The following 3 commands install unbound, backup your DNS configuration and tell
the system to use the local unbound:
apt install unbound
cp /etc/resolv.conf /etc/resolv.conf.backup
echo nameserver 127.0.0.1 > /etc/resolv.conf
To avoid that the configuration gets changed (for example by the DHCP client):
chattr +i /etc/resolv.conf
The Debian configuration ships with QNAME minimisation (RFC7816) enabled by
default so you don't need to enable it explicitly. The unbound resolver you just
installed does also DNSSEC validation.
===== CentOS/RHEL Install the unbound package:
yum install unbound
in /etc/unbound/unbound.conf replace the line
# qname-minimisation: no
with:
qname-minimisation: yes
enable and start unbound:
systemctl enable unbound
systemctl start unbound
Tell the system to use the local unbound server:
cp /etc/resolv.conf /etc/resolv.conf.backup
echo nameserver 127.0.0.1 > /etc/resolv.conf
To avoid that the configuration gets changed (for example by the DHCP client):
chattr +i /etc/resolv.conf
===== FreeBSD
FreeBSD ships unbound in the base system but the one in ports is usually
following upstream more closely so we install the unbound package:
pkg install unbound
Replace the content in /usr/local/etc/unbound/unbound.conf with the following
lines:
server:
verbosity: 1
qname-minimisation: yes
enable and start the unbound service:
sysrc unbound_enable=YES
service unbound start
Tell the system to use the local unbound server:
cp /etc/resolv.conf /etc/resolv.conf.backup
echo nameserver 127.0.0.1 > /etc/resolv.conf
To avoid that the configuration gets changed (for example by the DHCP client):
chflags schg /etc/resolv.conf
==== Exit Policy
Define your exit policy. The exit policy defines which destination ports you are
willing to forward. This has an impact on the amount of abuse emails you will
get (less ports means less abuse emails, but an exit relay allowing only few
ports is also less useful). If you want to be a useful exit relay you must at
least allow destination ports 80 and 443.
As a new exit relay - especially if you are new to your hoster - it is good to
start with a reduced exit policy (to reduce the amount of abuse emails) and
further open it up as you become more experienced. The reduced exit policy can
be found on the following page: [/wiki/doc/ReducedExitPolicy ReducedExitPolicy]
==== Final Step: Enable Exiting in your torrc configuration
To become an exit relay change ExitRelay from 0 to 1 in your torrc configuration
file and restart the tor daemon.
ExitRelay 1
=== Tor relay lifecycle
It takes some time for relay traffic to ramp up, this is especially true for
guard relays but to a lesser extend also for exit relays. To understand this
process, read about the lifecycle of a new relay:
https://blog.torproject.org/lifecycle-new-relay.
=== Maintaining a relay
==== Backup Tor Identity Keys
After your initial installation and start of the tor daemon it is a good idea to
make a backup of your relay's long term identity keys. They are located in the
"keys" subfolder of your DataDirectory (simply make a copy of the entire folder
and store it in a secure location). Since relays have a ramp-up time it makes
sense to backup the identity key to be able to restore your relay's reputation
after a disk failure - otherwise you would have to go through the ramp-up phase
again.
Default locations of the keys folder:
* Debian/Ubuntu: /var/lib/tor/keys
* FreeBSD/HardenedBSD: /var/db/tor/keys
==== Subscribe to the tor-announce mailing list This is a very low traffic
mailing list and you will get information about new stable tor releases and
important security update information.
* https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-announce
==== Setting up outage notifications
Once you setup your relay it will likely run without much work from your side.
If something goes wrong it is good to get notified automatically. We recommend
you use one of the free services that allow you to check your relay's ORPorts
for reachability and send you an email should they become unreachable for what
ever reason.
UptimeRobot is one of these services that allow you to monitor TCP listeners on
arbitrary ports. This service can check your configured ports once every 5
minutes and send you an email should your tor process die or become unreachable.
This checks only for the listener but does not speak the Tor protocol.
* https://uptimerobot.com/
A good way to monitor a relay for its health state is to have a look at its
bandwidth graphs.
==== System Health Monitoring To ensure your relay is healthy and not
overwhelmed it makes sense to have some basic system monitoring in place to keep
an eye on the following metrics:
* Bandwidth
* Established TCP Connections
* Memory
* Swap
* CPU
There are many tools for monitoring this kind of data, munin is one of them and
is relatively easy to setup.
Note: Do not make your private monitoring data graphs public since this could
help attackers with deanonymizing Tor users.
Some practical advice:
* If you want to publish traffic statistics, you should aggregate all your
relays' traffic over at least a week, then round that to the nearest 10 TiB
(terabytes).
* Reporting individual relays is worse than reporting totals for groups of
relays. In future, tor will securely aggregate bandwidth statistics, so any
individual relay bandwidth reporting will be less secure than tor's
statistics.
* Smaller periods are worse.
* Numbers are worse than graphs.
* Real-time data is worse than historical data.
* Data in categories (IP version, in/out, etc.) is worse than total data.
==== Tools This section listsm a few tools that you might find handy as a Tor
relay operator.
Nyx: Nyx is a Tor Project tool (formerly arm) that allows you to see real time
data of your relay.
vnstat: vnstat is a command-line tool that shows the amount of data going
through your network connection. You can also use it to generate PNG pictures
showing traffic graphs.
vnstat documentation and demo output:
* http://humdi.net/vnstat/
* http://humdi.net/vnstat/cgidemo/
== Part three: legal info, social info, and more resources === Legal
considerations (for exit relay operators)
Exit relay operators should understand the potential risks associated with
running an exit relay. For the majority of operators in most countries, bridges
and guard/middle relays are very low risk. Exits are the ones that present some
legal concerns, but operators under most circumstances will be able to handle
legal matters by having an abuse response letter, running the exit from a
location that isn't their home, and reading through some of the legal resources
that Tor-supportive lawyers have put together.
==== Legal resources
The EFF Tor Legal FAQ (https://www.torproject.org/eff/tor-legal-faq.html.en)
answers many common questions about relay operation and the law. We also like
Noisebridge's wiki for additional legal resources:
https://www.noisebridge.net/wiki/Noisebridge_Tor/FBI. In general it's a good
idea to consult with a lawyer before deciding to operate an exit relay,
especially if you live in a place where exit relay operators have been harassed,
or if you're the only exit relay operator in your region. Get in touch with your
local digital rights organization to see if they have recommendations about
legal assistance, and if you're not sure what organizations are working in your
region, write to EFF and see if they can help connect you:
https://www.eff.org/about/contact.
Also see the [/wiki/doc/TorExitGuidelines Tor Exit Guidelines].
RESPONDING TO ABUSE COMPLAINTS
Operators can put together their own abuse complaint template responses from one
of many templates that Tor has created: [/wiki/doc/TorAbuseTemplates
TorAbuseTemplates].
It is important to respond to abuse complaints in a timely manner (usually
within 24 hours). If the hoster gets annoyed by the amount of abuse you can
reduce the amount of ports allowed in your exit policy. Please document your
experience with new hosters on the follwoing wiki page: [/wiki/doc/GoodBadISPs
GoodBadISPs]
Other docs we like:
* a letter Boing Boing used to respond to a US federal subpoena about their
exit relay:
https://boingboing.net/2015/08/04/what-happened-when-the-fbi-sub.html
* abuse response templates from Coldhak, an organization in Canada that runs
multiple relays:
https://github.com/coldhakca/abuse-templates/blob/master/dmca.template,
https://github.com/coldhakca/abuse-templates/blob/master/generic.template
RUNNING A RELAY WITH OTHER PEOPLE
Running relays is more fun with other people! You can work with your university
department, your employer or institution, or an organization like Torservers.net
to run a relay.
TORSERVERS.NET
Torservers is an independent, global network of organizations that help the Tor
network by running high bandwidth Tor relays. Becoming a Torservers partner is a
good way to become more involved in the Tor relay community, and can help you
connect with dedicated relay operators around the world for solidarity and
support. To start a Torservers partner, the most important thing is to have a
group of people (3-5 suggested to start) interested in helping with the various
activities required for running relays. There should be mutual trust between the
people in the group, and members should commit to running relays for the long
term. If you do not know anyone in your social network interested in running
relays, one place to meet people is your local hackerspace:
https://wiki.hackerspaces.org/Hackerspaces.
Once you have a trusted group of people, depending on your region, it is often
advised to create some type of non-profit corporation. This is useful for having
a bank account, shared ownership, grant applications, etc. In many countries
operating as a corporation instead of as an individual can also get you certain
legal protections.
The next steps are figuring out hardware, transit, and server hosting. Depending
on your location and connections within the technical community of the area, the
last one may be the hardest step. Small local ISPs often have extra bandwidth,
and may be interested in supporting your group with some bandwidth or rackspace.
It is extremely important to maintain good relationships with these ISPs.
AT YOUR UNIVERSITY
Many computer science departments, university libraries, and individual students
and faculty run relays from university networks. These universities include the
Massachusetts Institute of Technology (MIT CSAIL), Boston University, the
University of Waterloo, the University of Washington, Northeastern University,
Karlstad University, Universitaet Stuttgart, and Friedrich-Alexander University
Erlangen-Nuremberg. To learn more about how to get support for a relay on your
university's network, check out EFF's resources:
https://www.eff.org/torchallenge/tor-on-campus.html.
AT YOUR COMPANY OR ORGANIZATION
If you work at a Tor-friendly company or organization, that's another ideal
place to run a relay. Some companies running relays inlcude Brass Horn
Communications, Quintex Alliance Consulting, and OmuraVPN. Some organizations
running Tor relays include Digital Courage, Access Now, Derechos Digitales, and
Lebanon Libraries in New Hampshire.
MORE RESOURCES
Congratulations, you're officially a Tor relay operator! What now?
* You can check out traffic and other statistics for your relay at our Relay
Search: https://metrics.torproject.org/rs.html (your relay will appear on
"Relay Search" about 3 hours after you started it).
* There is also more info about running a relay at the Tor FAQ:
https://www.torproject.org/docs/faq.html.en#HowDoIDecide.
* And, most importantly, make sure to email tshirt@torproject.org and claim
your swag: https://www.torproject.org/getinvolved/tshirt.html. It's our way
of saying thanks for defending privacy and free speech online.
=== How to file a "bugreport" for this guide
Please file a trac [/newticket ticket] and choose the component: Community/Relay
On this page
* The content on this page is no longer maintained.
* Why run a Tor relay?
* Exit relay
* Bridge
* Relay Requirements
* Tor Relay Setup: Installation and Configuration
* Responding to abuse complaints
* Running a relay with other people
* Torservers.net
* At your university
* At your company or organization
* More resources
SEITEN
1619
* AnonOnWikiFavs
* AppArmorForTBB
* AutomationInventory
* BlockingBittorrent
* CamelCase
* CI
* community
* relay_infrastructure
* CrowdfundingHS2015
* cypherpunks
* doc
* 1 1 1 task exchange
* AChildsGardenOfPluggableTransports
* AmazonCloud
* AnalysisTicketResults
* AppArmorForTBB
* arm
* Atlas
* badRelays
* trotskyIps
* BandwidthAuthority
* BandwidthAuthorityMeasurements
* BandwidthLimitChangeController
* BIND
* bitcoin
* BlockingDiagnostics
* BlockingIrc
* BlockingNonTorTraffic
* BlockNonTorTrafficDebian
* Bootstrap
* build
* AddingBuildSlaves
* BuildSignoff
* ListOfPackages
* CAPTCHAMonitor
* CentralizedTorServer
* CloudflareSites
* CodingForTor
* CodingInC
* CodingInR
* LoggingAndDocumentation
* CollecTor
* AnalysisDescriptorCompleteness
* AnalysisDescriptorCompletenessFromScratch
* AnalysisVotesAndConsensusCompleteness
* CollecTorServerConfigUsed
* DescriptorDistribution
* Improvements
* community
* blog comment policy
* glossary
* HowToReportBugFeedback
* ConnectOverSSH
* ContestEntries
* DesignFeedback
* crashreporter
* CronBandwidthLimit
* DataExtractionForComparison
* DebianDreamPlug
* DebianLive
* DirauthEd25519Keys
* directory_authority
* DNS_Resolver
* DNSHijacking
* DnsPluggableTransport
* Survey
* DnsResolver
* maraDeadwoodDns
* PublicDnsResolvers
* TestDnsResolving
* unbound
* doc
* TorBrowser
* Release_Schedule
* DocumentationList
* DreamPlug
* EC2Account
* emailLists
* EmailProvider
* EmailProviderComparison
* EmbeddedTips
* Excito
* exit relay
* ExitEnclave
* ExoneraTor
* Improvements
* FallbackDirectoryMirrors
* FAQUnanswered
* farsi bridges
* farsi tor
* FirefoxRemoteDNS
* FireFoxTorPerf
* fte
* setup
* GAEuploader
* GeneratingDirauthKeys
* GoAgent
* GoodBadISPs
* GoogleSeasonOfDocs2019
* gsoc
* Gsoc2009
* gsod
* HardeningAndroid
* HardwarePerformanceCompendium
* HiddenServiceEvangelism
* HiddenServiceNames
* HostingLocations
* HowBigIsTheDarkWeb
* HowTo_post_on_or talk_mailinglist
* HowToReleaseTor
* HTTPSEverywhere
* GSOC 2012
* SSLObservatorySubmission
* ImportantGoogleChromeBugs
* IPv6RelayHowto
* ISPCorrespondence
* JanusVM
* l10n coordinator
* LegalStuff
* Linux_TBB_Upgrade_Script
* LinuxDNSresolverForOnions
* ListOfTorImplementations
* LiveCDBestPractices
* MacBuild
* MacRunOnBoot
* meek
* SampleClientHellos
* Metrics2017Tickets
* MetricsGeoipComparison
* MetricsTimeline
* Mobile
* Modes_Of_Anonymity
* MonitoringFramework
* MultipleTorBrowsers
* MultiTor
* MyRelayIsSlow
* NewGuardAlgorithmTesting
* NextGenOnions
* non exit relay
* Novena
* nyx
* bugs
* obfsproxy
* obfsonportx
* OnionCat
* OnionizeHOWTO
* ftp_tor_service
* legal
* Onionoo
* Improvements
* OnionServiceNamingSystems
* OONI
* android
* Architecture
* Backend
* DNSResolver
* HTTPServer
* CensorshipDetectionTools
* 403Checker
* alkasir
* Herdict
* Netalyzr
* NeuBot
* ProjectBismark
* Switzerland
* Template
* CensorshipSimulator
* censorshipwiki
* CensorshipByCountry
* China
* Ethiopia
* Iran
* Kazakhstan
* Syria
* Template
* The_Philippines
* UAE
* Venezuela
* CensorshipCircumvention
* TorChanges
* CensorshipDetection
* PcapAnalysis
* TorCensorshipAnalyzer
* DataCollection
* DevelopmentWorkflow
* doc
* OONI
* censorshipwiki
* CensorshipResearch
* Methodology
* SetupHowto
* Tests
* BridgeT
* CaptivePortal
* d0wser
* daphne
* DNSInjection
* DNSLookup
* HeaderFieldManipulation
* HTTPHost
* HTTPScan
* KeywordFiltering
* Networklatency
* RSTPacketDetection
* Switzerland
* TestTemplate
* Traceroute
* TwoWayTraceroute
* TestWritingMethodology
* ThreatModel
* TODO
* OpenbsdChrootedTor
* OpenbsdChrootedTorControlScript
* OpenbsdChrootedTorScript
* OpenWRT
* OperationalSecurity
* packages
* PerformanceARMStatistics
* PETS2011EthicsPanel
* PluggableTransports
* BabyNameBook
* basket2evaluation
* Dust2Evaluation
* FlashProxy
* FAQ
* Howto
* Usability
* FlashproxyEvaluation
* FteEvaluation
* GuidelinesForDeployingPTs
* GuidelinesForRetiringPTs
* ideas
* list
* MeekEvaluation
* meetings
* 20130913BiWeeklyPT
* 20130927BiWeeklyPT
* Obfs2Evaluation
* Obfs3Evaluation
* Obfs4Evaluation
* obfs4proxy
* OthersCircumventionSystems
* PTEvaluationCriteria
* ScrambleSuitEvaluation
* SnowFlakeEvaluation
* Stegotorus
* WorkListForDevsToHelpOutWith
* Portable_Tor
* potentiallyDangerousRelays
* Prevent_DNS_Leaks
* Preventing_Tor_DNS_Leaks
* PreventingDnsLeaksInTor
* PrivoxyConfig
* PrivoxyPatches
* project_directory
* proper
* proxy
* Publicfile
* ReducedExitPolicy
* RemailingAndTor
* ReportingBadRelays
* ResearchEthics
* RunTwoPrivoxys
* SetupTorRelaywithKVM
* Snowflake
* Fingerprinting
* SnowflakeProxyAndroid
* SponsorODrafts
* SponsorOModules
* SshPortForwardedTor
* stem
* bugs
* support
* Android
* Calendar
* Coordination
* Introduction
* KnownIssues
* Template1
* Template2
* Template3
* Template4
* Template5
* Template6
* Template7
* Template8
* Template9
* Template10
* videos
* webchat
* SupportPolicy
* SupportPolicy_v2
* SupportPrograms
* Clamav
* git
* Polipo
* talks
* MoscowState2010
* TB
* TermsObserved
* Testing
* TBBSmokeTest
* Tools
* tgcw_ansero_html
* tgcw_article_txt
* tgcw_irssi_script
* tgcw_list_instructions
* tgcw_myth_catalog
* tgcw_people_voice
* tgcw_readme_short
* tgcw_what_to_do
* Tips_to_running_tor_bridges
* Tor friendly application best practices
* Tor_friendly_applications_best_practices
* tor teachers
* tor2web
* TorAbuseTemplates
* TorALaymansGuide
* TorBOX
* ApplicationWarningsAndNotes
* Authorship
* BareMetalHints
* bridges
* Changelog
* defunct
* DesignDocument
* DesignDocumentBase
* Dev
* ArchivedDiscussion
* DOCUMENTATION
* INFRASTRUCTURE
* MISC
* OPTIONALFEATURE
* QUESTIONS
* SECURITY
* SHELLSCRIPTS
* Build
* BuildDocumentation
* 0.1.3
* 0.2.1
* 0.3.0
* BuildScript
* ChangeRoot
* Chroot
* ClientVM
* CreateVM
* Debootstrap
* GetISO
* HardenedGentooTG
* Image
* ModifyISO
* MountVDI
* RelatedTickets
* ScriptSnippets
* TGScript
* timesync
* TorBOX Vbox
* torcheck
* TWScript
* DISCLAIMER
* Download
* FAQ
* Firewall
* History
* HowToInstall
* LeakTests
* LeakTestsOld
* ManualConfiguration
* OneVM
* OptionalConfigurations
* TunnelingUDPoverTor
* OtherAnonymizingNetworks
* OtherOperatingSystems
* PPTP
* Readme
* SecurityAndHardening
* ShellScript
* SimilarProjects
* TestAndTroubleshoot
* thttpd
* TorBox.org
* Trust
* Update
* TBB
* VMware
* XChat
* XChatDefaultConfigurationFiles
* TorBrowser
* Bad_TorBrowsers
* BuildingWithGitian
* Contributors
* DefaultBridges
* Hacking
* DebuggingOnWindows
* Hardening
* Platform_Installation
* Release_Schedule
* Sandbox
* Linux
* SmartOS_Sandboxing
* Supported_Platforms
* Triaging
* Updating
* VMSetup
* TorBrowserBundle
* OSX
* Security
* TorBrowserBundle3FAQ
* TorButtonChrome
* TorChutneyGuide
* TorCitadel
* TorControlPortWalkthrough HS
* TorDNSExitList
* TorDreamPlug
* TorExitGuidelines
* TorFAQ
* TorFragileHardening
* TorGuideUniversities
* TorifyHOWTO
* apt
* BitTorrent
* BridgeFirewall
* dnf
* EMail
* Thunderbird
* Thunderbird test
* Filezilla
* FTP
* general
* GnuPG
* HexChat
* InstantMessaging
* IRC
* Irc
* IrcSilc
* irssi
* IsolatingProxy
* legal
* mediawiki
* Misc
* Putty
* Mumble
* Polipo
* Putty
* SILC
* socat
* ssh
* SystracePolicy
* WebBrowsers
* WeeChat
* XChat
* XChatDefaultConfigurationFiles
* TorInChroot
* TorInTheMedia
* TorIPCOP
* TorLauncherUX2016
* TorMessenger
* DesignDoc
* FAQ
* MARGeneration
* Release
* Roadmap
* 2015
* SASL
* TorMirror
* TorNotes
* TorObfsBridgeSetupForBeginners
* TorOnDebian
* PackagesForArchitectures
* Torouter
* ExcitoB3
* notes
* FBmeetsTR
* OpenWRT_setup_notes
* OSXUSBIssues
* Roadmap
* TorPlusVPN
* TorProcessShare
* TorQA
* TBBQA
* tordriver notes
* TorRelaySecurity
* OfflineKeys
* TorShirt
* torsocks
* History
* TorToggle
* TorVPN
* Torwin32DNS
* TorWin32TorWS
* translation
* developers
* GlossaryFR
* ideas
* Introduction
* rules
* Transocks
* TransocksifyingTor
* TransparentProxy
* TransparentProxyLeaks
* TSocksPatches
* UpdatingFallbackDirectoryMirrors
* FallbackEmailTemplate
* UserThreatModels
* UsingTorWithVservers
* UX
* MetricsRedesign
* OoniUiDesign
* OrfoxSecuritySlider
* SupportPage
* VerifyingSignatures
* VM
* VMWareThroughTor
* weather in 2014
* WebProxyHowto
* Wikipedia
* WindowsBufferProblems
* windowsServiceProcessThreadPriorityAffinity
* docs
* OONI
* Backend
* HTTPServer
* censorshipwiki
* CensorshipDetection
* FlashProxyFAQ
* FlashProxyHowto
* FlashProxyUsability
* Home
* HTTPSEverywhere
* SSLObservatorySubmission
* ImportantGoogleChromeBugs
* infrastructure
* support.torproject.org
* InterMapTxt
* InterTrac
* InterWiki
* LikelyTMViolators
* NetworkTeamRestrospectiveSummerDev2015
* Onboarding general
* OnionSpace
* OperatorsTips
* DebianUbuntuConfiguringYourTorRelay
* RPMUpdates
* org
* CommunityCouncil
* doc
* ListOfServicesBlockingTor
* meetings
* 2010TorAnnualDevMeeting
* 2011MiniDevMeeting
* notes
* 2011StockholmHackfest
* 2011TorAnnualDevMeeting
* BountiesAndBowties
* FirehoseOutput
* LegalPrivacyAnonymity
* TorBrowserSessionNotes
* 2012FlorenceHackfest
* 2012FrankfurtHackfest
* 2012SeattleHackfest
* 2012SummerDevMeeting
* Notes
* D2S2PluggableTransports
* InternalServices
* ResearchIntegration
* S1CensorshipCircumvention
* S1Crypto
* S1OpSec
* TheTopicBrainstorm
* TransparencyComms
* PETSpedition
* 2012Toorcamp
* 2012WinterDevMeeting
* 2013CircumventionTechSummit
* Hackathon
* 2013SummerDevMeeting
* BundleUpdatePlan
* Fundraising
* LoveForVolunteers
* MailingLists
* OpSec
* PathSelection
* PluggableTransports0
* PluggableTransports1
* ResearchDirector
* ServiceInfrastructure
* Timesheets
* TorCrypto
* WebsiteTranslation
* 2013WinterDevMeeting
* 2014SummerDevMeeting
* Roadmaps
* SupportDiscussion
* TorBlockingDiscussion
* TorMessenger
* 2014WinterDevMeeting
* notes
* BridgeBundles
* BridgeProtocolsAndTBB
* ChatSupportPlans
* DRLRelaunch
* GuardDesign
* InterteamCoordination
* PeopleManagement
* PTMetrics
* PTTBB
* RoadmapTIMB
* RoleInventory
* SuggestionsForNextDevMeeting
* SupportAndTorBrowserTeamsMeeting
* SupportForExternalSoftwareUsingTor
* TBBCommunicationsChannels
* TBBReleaseProcess
* TorBerlinOffice
* TorBrowserPlan
* TorMonthlyReports
* TorOnMobile
* TorReleaseProcess
* TorRoadmap
* TorRoadmapAndProcess
* UserStories
* Volunteering
* 2015HiddenServiceMeeting
* 2015SummerDevMeeting
* AddressingDenialOfServiceAttacks
* AgendaQuestions
* ApplicationsTeam
* AroundTheTorWorld
* CodeOfConduct
* Community
* ExecutiveDirectorSearch
* AsksWeShouldMakeFromOtherOrganizationsAndAllies
* BootstrapBlockingResistance
* CodeReviews
* DirectoryAuthorityOperators
* iOS and OS X
* IPv6Roadmap
* LiveStreamingOnion
* MeasurementTeam
* MembershipProcess
* NetworkTeamRestrospective
* Notes
* OpSec101
* PTMeeting
* RelayOpsMeeting
* ResearchEthicsNotes
* Roadmap
* Apps
* Community
* HiddenServices
* HuggableTransports
* Measurements
* Mobile
* TBB
* TeachingTor
* ThreatModeling
* Tor2Web
* TorProcessShare
* WritingCoreTorPatches
* 2015UXMiniDevMeeting
* 2015UXsprint
* 2015WinterDevMeeting
* AgendaQuestions
* Feedback
* fund raising
* Notes
* AMA
* CommunityHealth
* CryptoChanges
* Cuba
* DirAuthDiscussion
* EcosystemMap
* FunderQuestionsAnswers
* GuardPriorities
* HelpForUnfundedProjects
* HiddenServicesRoadmap
* HR
* Media
* MobileTech
* OONI ICD Questions
* Projects
* Research
* RoadmapPics
* SecureServerRouting
* Strategy
* SupportingResearchCommunity
* SupportingUsers
* TorIn5Years
* TorPerformance
* TorPlatform
* TorValues
* TorWinsAndStories
* UXSprintRecap
* Venezuela
* VolunteersAndCommunity
* Projects
* 2016BerlinMeetup
* AgendaIdeas
* 2016SummerDevMeeting
* [org
* meetings
* 2016SummerDevMeeting
* Notes
* SecureOSOverview
* AgendaIdeas
* GrantMaking
* Notes
* AntiFingerprinting
* CommunityCouncil
* GetTor
* GrowingTor
* MeasuringTor
* Messaging
* OnionServiceApplications
* OONIDetectingBlockingOfThirdPartyApps
* SecureOSOverview
* SecurityIssuePolicy
* SupportPortal
* TalkingAboutTor
* UserRisk
* WebsiteFingerprinting
* ParticipantGuidelines
* 2016SummerMeeting
* 2016WinterDevMeeting
* AgendaIdeas
* Notes
* CodeReviews
* CommunityRoadmap
* ConsensusTransparency
* CoreTor
* CoreTorRoadmap
* CoreTorSponsoredSaved
* CrowdfundingCampaign
* CryptoChanges
* DirectoryAuthorityOperators
* Diversity
* Fundraising
* GetTor
* GovermentInterface
* HardwareAndTor
* InternalCommunications
* IPv6
* MembershipProcess
* MetricsRoadmap
* MobileRoadmap
* Onboarding
* OnionServicesRoadmap
* OONIRoadmap
* OONISession
* Opsec
* OTFProposals
* PluggableTransports
* PluggableTransportsRoadmap
* PressWork
* ProjectManagementAndUX
* RelayOps
* RemoteWorking
* Research
* SecureUserMeasurementAndData
* Snowflake
* SysAdmin
* TakeBackCommunityChannels
* Tor2020
* TorApplicationsAndResearch
* TorBoard
* TorBrowser
* TorBrowserRoadmap
* Torientation
* TorLabs
* TorMessengerRoadmap
* TorMobileReview
* TorOnMobile
* TorSocialContract
* TorVision
* TrainingAndOutreach
* UXII
* UXTorLauncher
* WebsiteMeeting
* WorkLiveBalance
* 2017Amsterdam
* 23March
* AgendaIdeas
* AgendaItems
* BrowserSecuritySettings
* GlobalSouth1
* IPv6Hackfest
* MobileStrategy
* Notes
* AntiCensorship
* BadRelays
* BetterFeedbackUserToDev
* bwauths
* CommunityTeamMtg
* CorpOnionServices
* DirAuths
* FindingTechnicalDebtsinTor
* Funding
* GlobalSouth1
* GlobalSouth2
* GrowingTorNetwork
* HowcanTorbemorewelcomingtodevelopers
* ipv6andTor
* MemorySafeLanguagesandTor
* Metricsin5Years
* MigratingTortoaMemorySafeLanguage
* mixnets
* MobileStrategy
* moderation
* NetworkTeam
* NoMoreTorin5Years
* OnionServices
* OnionServicesBlueSkySession
* OONIandTorMetrics
* OrgandCommunity
* organdcommunity
* OSUX
* PluggableTransports
* PQCrypto
* SecuritySliderUsability
* Sponsor4
* StrategicAdversaries
* ThreatModelingForFascism
* TorBrowserQA
* Toronallthings
* TorResearch
* TorUsers
* Trac
* UserSupport
* VegasTeamsandBeyond
* ZcashandTor
* ParticipantGuidelines
* UXforDevelopers
* 2017BuenosAiresMeetup
* 2017LAVITS
* 2017Montreal
* AgendaIdeas
* IPv6Hackfest
* Notes
* BusFactor
* BWAuthandTorScanning
* CDNsAndTorExitBlocking
* CloudflareNextSteps
* CommunityTeam
* CommunityTeamMeeting
* EncouragingThirdPartyIntegrationAndOnionServicesEverywhere
* FocusingOnFundedNotOnNeeded
* GlobalSouth
* GuardDiscovery
* IntegratingOnions
* InterTeamComms
* MetricsRoadmap
* MetricsTimeline
* MetricsTimelineWorkshop
* NetworkDiversity
* NetworkTeamRetrospective
* OnionsOnTheGo
* OONI TorBrowserCollaboration
* OONIMetrics
* PluggableTransports
* PrivCount
* RelaySession
* Rust
* ThinkingDifferentlyAboutFundingTor
* TorInChina
* TorOutsideOfFiveEyes
* TorRelayOperators
* UserSupport
* WebsiteRedesign
* OpenDays
* ParticipantGuidelines
* TeamMeetingSchedule
* 2017PrimaveraHacker
* 2017SaoPauloMeetup
* 2017Wilmington
* 2018MexicoCity
* AgendaIdeas
* CodigoDeConducta
* DailyAgenda
* linguine
* MTG
* Notes
* AltSvcOnions
* AntiCensorshipTeam
* BandwidthScanner
* BridgeDB
* ChinaCensorship
* CI
* CommunityPortalMapping
* EmbeddingTorInAndroid
* ExecutiveDirectorTransition
* Finances and Fundraising
* FPI
* Fundraising Brainstorm
* GDPR
* globalsouth day1
* globalsouth day2
* HTTPSEverywhereNotes
* IntegratingTorOtherBrowsers
* LFI
* Linguine
* Localization
* Mobile
* NetworkTeamContinuousIntegration
* NextMeeting
* OnionV3ux
* OONIDataFormatPain
* OONIRapidResponse
* PluggableTransports
* PrivCount
* PrivCountTechnical
* Research
* RustLinking
* SandboxedTorBrowser
* TBBMeetingDays
* TechnicalDebt
* TorAndTails
* TorAtIFF
* TorBrowserUX
* TorPerformance
* TorUpliftRoadmap
* TorVenezuela
* UserStories
* Vanguards
* VolunteerOnboarding
* ParticipantGuidelines
* PublicDays
* 2018NetworkTeamHackfestSeattle
* CI
* DoS
* LargePatches
* LTS
* MemoryProfiling
* Modularisation
* OldCrypto
* privcount
* Quic
* RelayCrypto
* sbws
* 2018Rome
* Age
* AgendaIdeas
* Dail
* DailyAgenda
* Notes
* BandwidthAuthorityRequirements
* CellCrypto
* CommunityMeeting
* CommunityPortalContent
* ContinuousIntegration
* DirectoryAuthorityOperatorsMeetup
* FloatingPointNoise
* FusionProject
* FutureTorNetworkProtocolUpgrades
* LocalizationLinguine
* NetworkTeam
* OneClickCensorshipCircumvention
* OoniNotifications
* OptimisticData
* PrioritiseStatisticsForPrivCountInTor
* PrivCountInTor
* PT
* RelaysAdvocate
* SwagForVolunteers
* TorBackboneFitness
* TorMeetingPlanning
* TorModularization
* UserIssues
* Open
* OpenDays
* ParticipantGuidelines
* TeamMeetingsDay
* Work
* WorkingSessions
* 2019Brussels
* Notes
* Onionperf
* 2019BrusselsAdminTeam
* 2019BrusselsAdminTeamMinutes
* 2019BrusselsMetricsTeam
* Notes
* 2019BrusselsNetworkTeam
* Notes
* 2years
* ChutneyPlanning
* Evaluation
* Modularization
* OtherExperiences
* privcount
* ReleasePlanning
* Research_FollowUp
* RetrospectiveTeamDiversity
* ReviewBestPractices
* SBWSRoadmap
* SharedAgreement
* Snowflake
* SnowflakeTrafficPatterns
* StableMaintainer
* WTF_Pad
* 2019Stockholm
* ArrivalDinner
* DailyAgenda
* MaterialsNeeded
* MTG
* Notes
* AntiCensorshipRapidResponse
* AntiCensorshipTeamRetrospective
* AntiCensorshipTeamRoadmapping
* AppEcosystemBranding
* BeginningCircle
* Blog
* BrowserTeamDayOne
* CapacityEstimation
* CommunityCouncilQA
* CommunityTeamRoadmapping
* DevPortal
* EmailNotEmail
* FirefoxTorUpliftAndTorModeAddOn
* FundraisingBrainstorm
* GrantsTeamRoadmapping
* GrowingTheTorNetwork
* GuestAccountsInTicketingSystem
* HowDoWeMaintainSbws
* InternalTooling
* MeaningfulNamesForOnions
* media.tpo
* MetricsTeamRoadmapping
* Moderation
* NetworkHealth
* NetworkTeamDayOne
* OONI
* OrganizationTimeAndProcessEfficienciesInefficiencies
* S9
* S27
* S28
* S30
* SAT
* ScalabilityProjectFunding
* SecurityTrainingBasics
* SnowflakeVolunteers
* StreamliningDevProcesses
* SysadminTeamRoadmapping
* TorAndTheClimateCrisis
* TorAppEcosystem
* TorBrowserRoadmapping
* TorHSM
* TorNamecoin
* UserIssuesPrioritization
* UserResearchCoordination
* UserResearchPersonas
* UXTeamRoadmapping
* v2tov3onions
* VolunteerPrograms
* WebsiteMaintenance
* 2019Valencia
* 2020Brussels
* 2020CostaRica
* 2020RightsCon
* 2020Valencia
* AthensMeetupMay19
* AthensTorMeetupJan18
* BerlinMeetupFeb19
* BerlinRelayOperatorsMeetupAug18
* BerlinRelayOperatorsMeetupJul18
* BrusselsMeetupNov25
* HamburgMeetupApr26
* HamburgMeetupAug18
* LisbonMeetupFeb19
* LiveStreamingOnion
* Meetups
* RomeRelayOperatorsMeetupMar18
* TorMeetingPlanning
* AgendaFollowupTemplate
* InvitationTemplate
* ParticipantWikiTemplate
* SaveTheDateTemplate
* TorMeetingTemplates
* ValenciaMeetupMar19
* Meetups
* onboarding
* EmailLists
* IRC
* operations
* Guidelines
* Infrastructure
* deb.torproject.org
* git.torproject.org
* Hosts
* Jabber
* lists.torproject.org
* NextCloud
* onionperf
* rt.torproject.org
* schleuder
* support.torproject.org
* trac migration
* infrastructure
* gitlab
* onionperf
* ProductsandAssignments
* services
* blog
* deb.torproject.org
* faq
* git.torproject.org
* gitlab
* Jabber
* lektor package
* lists.torproject.org
* newsletter
* nextcloud
* nextcloud_evaluation_phase
* oniongit
* onionperf
* roadmaps
* rome2018
* rt.torproject.org
* schleuder
* storm
* styleguide
* support
* survey
* trac
* website
* process
* HowWeDoProjectManagement
* IsabelaNotes
* ProjectManagementTools
* SetUpProjectMgt
* TorAgileProcess
* TorOnTrac
* projects
* 2013InfrastructureUpgrade
* DontBlockMe
* projectM
* BoF_18_1_2013
* brainstorming
* Tor
* CipherList
* MultithreadedCrypto
* TLSHistory
* WeSupportTor
* research
* MozillaResearchRFP
* Projects
* roadmaps
* BridgeDB
* CoreTor
* 2015SummerCoreTorRoadmap
* 2015WinterCoreTorRoadmap
* 2016WinterCoreTorRoadmap
* PerformanceExperiments
* PerformanceMetrics
* FundRaising
* GetTor
* design
* future
* usage
* HS
* Media
* OONI
* Org
* people
* NickM
* Thandy
* Tor
* 023
* 024
* 025
* TicketTriage025
* HiddenServices
* IPv6
* PrivateIPv6TestingNetwork
* IPv6Features
* Performance
* TCT
* TorBrowser
* 2015SummerTorBrowserRoadmap
* 2015WinterTorBrowserRoadmap
* 2016WinterTorBrowserRoadmap
* TorBulkExitlist
* TorButton
* TorCheck
* TorFlow
* TorObfuscation
* TorStatus
* Vidalia
* Weather
* Website
* sponsors
* CoreTorTeam Dec:16 Jan:17 Report
* CoreTorTeam February 2017 Report
* NightOwl
* Pantheon
* Chronos
* Sponsor2
* Sponsor2 2019 outcomes
* Sponsor3
* Sponsor3 2018 outcomes
* Sponsor4
* Sponsor5
* Sponsor6
* Sponsor7
* Sponsor8
* Sponsor9
* Sponsor11
* Sponsor12
* Sponsor13
* Sponsor14
* Sponsor15
* Sponsor16
* Sponsor17
* Sponsor18
* Sponsor19
* Sponsor20
* Sponsor21
* Sponsor22
* sponsor22
* Sponsor23
* Sponsor24
* Sponsor27
* Sponsor28
* Sponsor30
* Sponsor31
* Sponsor32
* Sponsor38
* Sponsor44
* Sponsor48
* Sponsor55
* Sponsor58
* Sponsor59
* Sponsor69
* SponsorA
* SponsorB
* SponsorE
* PhaseOne
* PhaseThree
* September2011
* SponsorF
* March2012
* November2011
* Year1
* Year2
* Year3
* Year4
* SponsorG
* SponsorH
* Coordination
* SponsorI
* SponsorJ
* SponsorK
* SponsorL
* SponsorM
* SponsorN
* SponsorO
* TorBrowserVideos
* Automation
* SponsorP
* SponsorQ
* SponsorQ 2018 outcomes
* SponsorR
* meetings
* 2014 11 18
* Reachability
* tasklist
* Terminology
* Year1
* SponsorRtasklist
* SponsorS
* IntegrationTesting
* Proposal
* Outreach
* PluggableTransports
* Proposal
* SponsorT
* SponsorU
* Tor
* TorBrowser
* SponsorV
* SponsorV 2019 outcomes
* SponsorW
* SponsorX
* SponsorZ
* TorBrowserTeam December 2016 Report
* TorBrowserTeam February 2017 Report
* TorBrowserTeam January 2017 Report
* Year2020
* Strategy
* SurveyFAQ
* teams
* AntiCensorshipTeam
* BridgeDBSurvivalGuide
* GetTorSurvivalGuide
* InfrastructureMonitoring
* NGOBridgeSupply
* NGOBridgeSupport
* SnowflakeBridgeInstallationGuide
* SnowflakeBridgeSurvivalGuide
* SnowflakeBrokerInstallationGuide
* SnowflakeBrokerSurvivalGuide
* ApplicationsTeam
* TeamMeetingTorSummer2016Meeting
* TorBrowserAndroid
* Roadmap
* CommunicationsTeam
* CommunityTeam
* DocsHackathon
* WelcomeTemplate
* Events
* LasVegas
* NYC
* issues
* Projects
* GlobalSouth
* Legal
* USPVolunteers
* RapidResponse
* RelayAdvocate
* supportportal
* trainings
* wiki
* org
* meetings
* 2018CryptoRaveIRCMeetingAgenda
* SizeCharts
* Support
* Support_discuss
* SwagForVolunteers
* Tshirts
* TshirtsForVolunteers
* FundraisingTeam
* Campaigns
* 2017
* 2018
* 2019
* MonthlyReports
* 2018August
* 2018December
* 2018January
* 2018November
* 2018October
* 2018September
* 2019April
* 2019August
* 2019December
* 2019February
* 2019January
* 2019July
* 2019June
* 2019March
* 2019May
* 2019November
* 2019October
* 2019September
* 2020February
* 2020January
* 2020March
* Roadmap2019
* Roadmap2020
* StateOfTheOnionJuly2019
* MetricsTeam
* ContributorGuide
* Documentation
* ExitScannerSurvivalGuide
* MetricsJavaStyleGuide
* MetricsPythonStyleGuide
* ObfuscationSimulationAnalysis
* OldRoadmaps
* RelaySearch
* Volunteers
* NetworkHealthTeam
* NetworkTeam
* AnnouncementTemplates
* Backports
* BandwidthAuthority
* sbws
* BugTriage
* CIFailures
* CommitterPolicy
* CoreTorReleases
* 040Status
* 041Status
* 042Retrospective
* 042Status
* 043Status
* 044Status
* FilingTicketNetworkTeam
* HackfestWilmingtonMeeting
* MainlineMerges
* MeetingPadTemplate
* MeetingSchedule
* MeetingTimeGuidelines
* MergePolicy
* MergeProcess
* MetaPolicy
* NetworkTeamProducts
* NetworkTeamRestrospectiveSummerDev2015
* PrivCountInTor
* PrivCountResearchRetrospective
* ReleaseGuidelines
* ReleaseParameters
* ReleasePolicy
* SecurityPolicy
* SecurityPolicyOld
* Sponsor4Design
* Sponsor4Plan
* Sponsor8
* SupportedPlatforms
* TeamMeetingTorSummer2016Meeting
* TeamRotations
* TicketTriage
* 035
* TorLibrarySize
* UsefulTicketsQueries
* OONI
* Operations
* SysadminTeam
* UxTeam
* GetTor
* Todo
* Misc
* CircuitDisplay
* OnionSecurityIndicator
* style_guide
* StyleGuidelines
* TorMail
* Todo
* TorMessenger
* Todo
* TorMobileBrowser
* History
* Todo
* UserResearch
* TorProjectCorporateDocuments
* TorSoP
* Outreachy
* 2018doclist
* PageTemplates
* postcts hackathon
* PrivateMode
* Prop271ImplementationPlan
* RecentChanges
* RustInTor
* Hacking
* SandBox
* sponsors
* SponsorF
* Year1
* Testing
* TBBSmokeTest
* Tools
* TheySupportCensorship
* TicketQuery
* TitleIndex
* Tor in Delhi
* TorArticles
* torbirdy
* changes
* dev
* installation
* preferences
* RoadMap
* TorBrowserBundle3SAQ
* TorBrowserBundleSAQ
* TorHSM
* TorObfsBridgeSetupForBeginners
* TorRelayGuide
* BSDUpdates
* CentOSRHEL
* DebianUbuntu
* DebianUbuntuUpdates
* DragonFlyBSD
* Fedora
* FreeBSD
* NetBSD
* OpenBSD
* openSUSE
* RPMUpdates
* Security
* Windows
* TorRelayGuide ptbr
* TorRelayGuideRevisions
* TorWeeklyNews
* 2013
* 0
* 1
* 2
* 3
* 4
* 5
* 6
* 7
* 8
* 9
* 10
* 11
* 12
* 13
* 14
* 15
* 16
* 17
* 18
* 19
* 20
* 21
* 22
* 23
* 24
* 25
* 2014
* 1
* 2
* 3
* 4
* 5
* 6
* 7
* 8
* 9
* 10
* 11
* 12
* 13
* 14
* 15
* 16
* 17
* 18
* 19
* 20
* 21
* 22
* 23
* 24
* 25
* 26
* 27
* 28
* 29
* 30
* 31
* 32
* 33
* 34
* 35
* 36
* 37
* 38
* 39
* 40
* 41
* 42
* 43
* 44
* 45
* 46
* 47
* 48
* 49
* 50
* 51
* 52
* 2015
* 1
* 2
* 3
* 4
* 5
* 6
* 7
* 8
* 9
* 10
* 11
* 12
* 13
* 14
* 15
* 16
* 17
* 18
* 19
* 20
* 21
* 22
* 23
* 24
* 25
* 26
* 27
* 28
* 29
* 30
* 31
* 32
* 33
* 34
* 35
* 36
* 37
* 38
* 2016
* 1
* 2
* BugsToPlug
* Linkify
* Numerize
* Template
* TracAccessibility
* TracAdmin
* TracBackup
* TracBatchModify
* TracBrowser
* TracCgi
* TracChangeLog
* TracChangeset
* TracEnvironment
* TracFastCgi
* TracFineGrainedPermissions
* TracGuide
* TracImport
* TracIni
* TracInstall
* TracInterfaceCustomization
* TracLinks
* TracLogging
* TracModPython
* TracModWSGI
* TracNavigation
* TracNotification
* TracPermissions
* TracPlugins
* TracQuery
* TracReports
* TracRepositoryAdmin
* TracRevisionLog
* TracRoadmap
* TracRss
* TracSearch
* TracStandalone
* TracSupport
* TracSyntaxColoring
* TracTickets
* TracTicketsCustomFields
* TracTimeline
* TracUnicode
* TracUpgrade
* TracWiki
* TracWorkflow
* TROVE
* user
* anarcat
* arma
* catalyst
* gaba
* juga
* monthtickets
* karsten
* Linda
* ln5
* phobos
* Samdney
* t0mmy
* tailscryptography
* teor
* Backlog
* HiddenBackports
* low
* RoadmapBacklog
* weasel
* UserIssuesResearch
* vanguards
* Website
* MainSiteRedesign
* WebsiteProposalClv
* WhyUseTorBrowserBundle
* WikiDeletePage
* WikiFormatting
* WikiHtml
* WikiMacros
* WikiNewPage
* WikiPageNames
* WikiProcessors
* WikiRestructuredText
* WikiRestructuredTextLinks
* WikiStartAlternate
* Метка1
* Яндекс
View all pages