tor-commits August 2019

tor-commits@lists.torproject.org

19 participants
2737 discussions

[community/staging] Rename directories in relay operations section
by pili＠torproject.org 02 Aug '19

02 Aug '19

commit 217d2842aa40b2ca0af506faeb8cbafa4f858385 Author: gus <gus(a)torproject.org> Date: Tue Jul 30 03:45:24 2019 -0400 Rename directories in relay operations section --- .../bridge/centos-rhel-opensuse/contents.lr | 101 ++++++++++++ .../technical-setup/bridge/contents.lr | 23 +++ .../bridge/debian-ubuntu/contents.lr | 80 +++++++++ .../technical-setup/bridge/freebsd/contents.lr | 98 +++++++++++ .../technical-setup/bridge/openbsd/contents.lr | 74 +++++++++ .../bridge/post-install/contents.lr | 22 +++ .../technical-setup/centosrhel/contents.lr | 19 --- .../technical-setup/debianubuntu/contents.lr | 19 --- .../technical-setup/exit/contents.lr | 181 +++++++++++++++++++++ .../technical-setup/fedora/contents.lr | 19 --- .../technical-setup/freebsd/contents.lr | 19 --- .../technical-setup/guard/centosrhel/contents.lr | 56 +++++++ .../technical-setup/guard/contents.lr | 15 ++ .../technical-setup/guard/debianubuntu/contents.lr | 46 ++++++ .../technical-setup/guard/fedora/contents.lr | 37 +++++ .../technical-setup/guard/freebsd/contents.lr | 73 +++++++++ .../technical-setup/post-install/contents.lr | 179 ++++++++++++++++++++ 17 files changed, 985 insertions(+), 76 deletions(-) diff --git a/content/relay-operations/technical-setup/bridge/centos-rhel-opensuse/contents.lr b/content/relay-operations/technical-setup/bridge/centos-rhel-opensuse/contents.lr new file mode 100644 index 0000000..5849e5a --- /dev/null +++ b/content/relay-operations/technical-setup/bridge/centos-rhel-opensuse/contents.lr @@ -0,0 +1,101 @@ +_model: page +--- +title: CentOS / RHEL / OpenSUSE +--- +body: + +# 1. Install tor and dependencies + +* Redhat / RHEL: + +``` +yum install epel-release +yum install git golang tor +``` + +* OpenSUSE: + +``` +zypper install tor go git +``` + +# 2. Build obfs4proxy and move it into place. + +Heavily outdated versions of git can make `go get` fail, so try upgrading to a more recent git version if you're running into this problem. + +* CentOS / RHEL: + +``` +export GOPATH=`mktemp -d` +go get gitlab.com/yawning/obfs4.git/obfs4proxy +sudo cp $GOPATH/bin/obfs4proxy /usr/local/bin/ +chcon --reference=/usr/bin/tor /usr/local/bin/obfs4proxy +``` + +* OpenSUSE: + +``` +export GOPATH=`mktemp -d` +go get gitlab.com/yawning/obfs4.git/obfs4proxy +sudo cp $GOPATH/bin/obfs4proxy /usr/local/bin/ +``` + +# 3. Edit your Tor config file, usually located at `/etc/tor/torrc` and add the following lines: + +``` +#Bridge config +RunAsDaemon 1 +ORPort auto +BridgeRelay 1 +ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy +# For a fixed obfs4 port (e.g. 34176), uncomment the following line. +#ServerTransportListenAddr obfs4 0.0.0.0:34176 +# Local communication port between Tor and obfs4. Always set this to "auto". "Ext" means +# "extended", not "external". Don't try to set a specific port number, nor listen on 0.0.0.0. +ExtORPort auto + +# Contact information that allows us to get in touch with you in case of +# critical updates or problems with your bridge. This is optional, so you +# don't have to provide an email address if you don't want to. +ContactInfo <address(a)email.com> +# Pick a nickname that you like for your bridge. +Nickname PickANickname +``` + +Don't forget to change the ContactInfo and Nickname options. + +* Note that both Tor's OR port **and** its obfs4 port must be reachable. If your bridge is behind a firewall or NAT, make sure to open both ports. + +# 4. Restart tor + +`systemctl restart tor` + +# 5. Monitor your logs (usually in your syslog) + +To confirm your bridge is running with no issues, you should see something like this: + +``` +[notice] Your Tor server's identity key fingerprint is '<NICKNAME> <FINGERPRINT>' +[notice] Your Tor bridge's hashed identity key fingerprint is '<NICKNAME> <HASHED FINGERPRINT>' +[notice] Registered server transport 'obfs4' at '[::]:46396' +[notice] Tor has successfully opened a circuit. Looks like client functionality is working. +[notice] Bootstrapped 100%: Done +[notice] Now checking whether ORPort <redacted>:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) +[notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. +``` + +Remember to open the random port associated with your bridge. You can find it in your tor log; in the above example it is 46396. To use a fixed port, uncomment the [ServerTransportListenAddr](https://www.torproject.org/docs/tor-manual.html.… option in your torrc. You can use [our reachability test](https://bridges.torproject.org/scan/) to see if your obfs4 port is reachable from the Internet. + + +--- +html: two-columns-page.html +--- +key: + +2 +--- +color: primary +--- +subtitle: How to deploy obfs4proxy Bridge on CentOS / RHEL / OpenSUSE +--- +_template: layout.html diff --git a/content/relay-operations/technical-setup/bridge/contents.lr b/content/relay-operations/technical-setup/bridge/contents.lr new file mode 100644 index 0000000..c83b3e6 --- /dev/null +++ b/content/relay-operations/technical-setup/bridge/contents.lr @@ -0,0 +1,23 @@ +_model: page +--- +title: + + Bridge +--- +body: + +This guide will help you run an obfs4 bridge to help censored users connect to the Tor network. The requirements are 1) 24/7 Internet connectivity and 2) the ability to expose TCP ports to the Internet (make sure that NAT doesn't get in the way). + +Note: If you're running platforms that are not listed on this page, you should probably [compile obfs4 from source](https://gitlab.com/yawning/obfs4#installation). +--- +html: two-columns-page.html +--- +key: 2 +--- +section: Bridge operations +--- +section_id: bridge-operations +--- +subtitle: Run an obfs4 bridge to help censored users connect to the Tor network +--- +_slug: {{bridge}} diff --git a/content/relay-operations/technical-setup/bridge/debian-ubuntu/contents.lr b/content/relay-operations/technical-setup/bridge/debian-ubuntu/contents.lr new file mode 100644 index 0000000..8900995 --- /dev/null +++ b/content/relay-operations/technical-setup/bridge/debian-ubuntu/contents.lr @@ -0,0 +1,80 @@ +_model: page +--- +title: Debian / Ubuntu +--- +body: + +# 1. Install Tor + +Get the latest version of Tor. If you're on Debian stable, `sudo apt-get install tor` should give you the latest stable version of Tor. + +* Note:''' Ubuntu users need to get it from Tor repository. Please see [Download instructions for Ubuntu](https://www.torproject.org/docs/debian.html.en#ubuntu). + +# 2. Install obfs4proxy + +On [Debian](https://packages.debian.org/search?keywords=obfs4proxy), the `obfs4proxy` package is available in sid, buster, and stretch. On [https://packages.ubuntu.com/search?keywords=obfs4proxy Ubuntu], bionic, cosmic, disco, and eoan have the package. If you're running any of them, `sudo apt-get install obfs4proxy` should work. + +If not, you can [build it from source](https://gitlab.com/yawning/obfs4#installation). + +# 3. Edit your Tor config file, usually located at `/etc/tor/torrc` and add the following lines: + +``` +#Bridge config +RunAsDaemon 1 +ORPort auto +BridgeRelay 1 +ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy +# For a fixed obfs4 port (e.g. 34176), uncomment the following line. +#ServerTransportListenAddr obfs4 0.0.0.0:34176 +# Local communication port between Tor and obfs4. Always set this to "auto". "Ext" means +# "extended", not "external". Don't try to set a specific port number, nor listen on 0.0.0.0. +ExtORPort auto + +# Contact information that allows us to get in touch with you in case of +# critical updates or problems with your bridge. This is optional, so you +# don't have to provide an email address if you don't want to. +ContactInfo <address(a)email.com> +# Pick a nickname that you like for your bridge. +Nickname PickANickname +``` + +Don't forget to change the ContactInfo and Nickname options. + +* If you decide to use a fixed obfs4 port smaller than 1024 (for example 80 or 443), you will need to give obfs4 `CAP_NET_BIND_SERVICE` capabilities to bind the port with a non-root user: + +``` +sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy +``` + +* Under Debian, you will also need to set `NoNewPrivileges=no` in `/lib/systemd/system/tor(a)default.service` and `/lib/systemd/system/tor@.service` and then run `systemctl daemon-reload`. [bug #18356](https://trac.torproject.org/projects/tor/ticket/18356) + +* Note that both Tor's OR port **and** its obfs4 port must be reachable. If your bridge is behind a firewall or NAT, make sure to open both ports. + +# 4. Restart tor + +`systemctl restart tor` + +# 5. Monitor your logs + +To confirm your bridge is running with no issues, you should see something like this (usually in `/var/log/tor/log` or `/var/log/syslog`): + + +``` +[notice] Your Tor server's identity key fingerprint is '<NICKNAME> <FINGERPRINT>' +[notice] Your Tor bridge's hashed identity key fingerprint is '<NICKNAME> <HASHED FINGERPRINT>' +[notice] Registered server transport 'obfs4' at '[::]:46396' +[notice] Tor has successfully opened a circuit. Looks like client functionality is working. +[notice] Bootstrapped 100%: Done +[notice] Now checking whether ORPort <redacted>:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) +[notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. +``` + +Remember to open the random port associated with your bridge. You can find it in your tor log; in the above example it is 46396. To use a fixed port, uncomment the [ServerTransportListenAddr](https://www.torproject.org/docs/tor-manual.html.… option in your torrc. You can use [our reachability test](https://bridges.torproject.org/scan/) to see if your obfs4 port is reachable from the Internet. + + +--- +key: 1 +--- +html: two-columns-page.html +--- +subtitle: How to deploy an obfs4proxy Bridge on Debian / Ubuntu diff --git a/content/relay-operations/technical-setup/bridge/freebsd/contents.lr b/content/relay-operations/technical-setup/bridge/freebsd/contents.lr new file mode 100644 index 0000000..01adcd2 --- /dev/null +++ b/content/relay-operations/technical-setup/bridge/freebsd/contents.lr @@ -0,0 +1,98 @@ +_model: page +--- +title: FreeBSD +--- +html: two-columns-page.html +--- +key: 3 +--- +body: + +# 1. Install packages + +``` +pkg install obfs4proxy-tor tor ca_root_nss +``` + +# 2. Edit your Tor config file, usually located at `/usr/local/etc/tor` and add the following lines + +``` +#Bridge config +RunAsDaemon 1 +ORPort auto +BridgeRelay 1 +ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy +# For a fixed obfs4 port (e.g. 34176), uncomment the following line. +#ServerTransportListenAddr obfs4 0.0.0.0:34176 +# Local communication port between Tor and obfs4. Always set this to "auto". "Ext" means +# "extended", not "external". Don't try to set a specific port number, nor listen on 0.0.0.0. +ExtORPort auto + +# Contact information that allows us to get in touch with you in case of +# critical updates or problems with your bridge. This is optional, so you +# don't have to provide an email address if you don't want to. +ContactInfo <address(a)email.com> +# Pick a nickname that you like for your bridge. +Nickname PickANickname + +Log notice file /var/log/tor/notices.log +``` + +Don't forget to change the ContactInfo and Nickname options. + +* Note that both Tor's OR port **and** its obfs4 port must be reachable. If your bridge is behind a firewall or NAT, make sure to open both ports. + +# 3. Ensure that the `random_id` sysctl setting is enabled: + +``` +echo "net.inet.ip.random_id=1" >> /etc/sysctl.conf +sysctl net.inet.ip.random_id=1 +``` + +# 4. Start the tor daemon and make sure it starts at boot: + +``` +sysrc tor_enable=YES +service tor start +``` + +# 5. Monitor your logs + +To confirm your bridge is running with no issues, you should see something like this in `/var/log/tor/notices.log`: + +``` +[notice] Your Tor server's identity key fingerprint is '<NICKNAME> <FINGERPRINT>' +[notice] Your Tor bridge's hashed identity key fingerprint is '<NICKNAME> <HASHED FINGERPRINT>' +[notice] Registered server transport 'obfs4' at '[::]:46396' +[notice] Tor has successfully opened a circuit. Looks like client functionality is working. +[notice] Bootstrapped 100%: Done +[notice] Now checking whether ORPort <redacted>:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) +[notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. +``` + +Remember to open the random port associated with your bridge. You can find it in your tor log; in the above example it is 46396. To use a fixed port, uncomment the [ ServerTransportListenAddr](https://www.torproject.org/docs/tor-manual.html.… option in your torrc. You can use[our reachability test] (https://bridges.torproject.org/scan/) to see if your obfs4 port is reachable from the Internet. + +# 6. To get the fastest package updates, switch from the "quarterly" package repo to the "latest" repo. + +Create the following folder: + +``` +mkdir -p /usr/local/etc/pkg/repos +``` + +Create the file `/usr/local/etc/pkg/repos/FreeBSD.conf` with the following content: + +``` +FreeBSD: { enabled: no } + +FreeBSDlatest: { + url: "pkg+https://pkg.FreeBSD.org/${ABI}/latest", + mirror_type: "srv", + signature_type: "fingerprints", + fingerprints: "/usr/share/keys/pkg", + enabled: yes +} +``` + +--- +subtitle: How to deploy obfs4proxy Bridge on FreeBSD diff --git a/content/relay-operations/technical-setup/bridge/openbsd/contents.lr b/content/relay-operations/technical-setup/bridge/openbsd/contents.lr new file mode 100644 index 0000000..ae682d9 --- /dev/null +++ b/content/relay-operations/technical-setup/bridge/openbsd/contents.lr @@ -0,0 +1,74 @@ +_model: page +--- +title: OpenBSD +--- +html: two-columns-page.html +--- +key: 4 +--- +body: + +# 1. Install packages +``` +pkg_add tor obfs4proxy +``` + +# 2. Edit your Tor config file + +Usually located at `/etc/tor/torrc`, add the following lines: + +``` +#Bridge config +RunAsDaemon 1 +ORPort auto +BridgeRelay 1 +ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy +# For a fixed obfs4 port (e.g. 34176), uncomment the following line. +#ServerTransportListenAddr obfs4 0.0.0.0:34176 +# Local communication port between Tor and obfs4. Always set this to "auto". "Ext" means +# "extended", not "external". Don't try to set a specific port number, nor listen on 0.0.0.0. +ExtORPort auto + +# Contact information that allows us to get in touch with you in case of +# critical updates or problems with your bridge. This is optional, so you +# don't have to provide an email address if you don't want to. +ContactInfo <address(a)email.com> +# Pick a nickname that you like for your bridge. +Nickname PickANickname + +Log notice file /var/log/tor/notices.log + +User _tor +``` + +Don't forget to change the ContactInfo and Nickname options. + +Note that both Tor's OR port and its obfs4 port must be reachable. If your bridge is behind a firewall or NAT, make sure to open both ports. + +# 3. Start the tor daemon and make sure it starts at boot: + +``` +rcctl enable tor +rcctl start tor +``` +# 4. Monitor your logs + +To confirm your bridge is running with no issues, you should see something like this (`/var/log/tor/notices.log`): + +``` +[notice] Your Tor server's identity key fingerprint is '<NICKNAME> <FINGERPRINT>' +[notice] Your Tor bridge's hashed identity key fingerprint is '<NICKNAME> <HASHED FINGERPRINT>' +[notice] Registered server transport 'obfs4' at '[::]:46396' +[notice] Tor has successfully opened a circuit. Looks like client functionality is working. +[notice] Bootstrapped 100%: Done +[notice] Now checking whether ORPort <redacted>:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) +[notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. +``` + +Remember to open the random port associated with your bridge. You can find it in your tor log; in the above example it is 46396. To use a fixed port, uncomment the [ServerTransportListenAddr](https://www.torproject.org/docs/tor-manual.html.… option in your torrc. You can use [our reachability test](https://bridges.torproject.org/scan/) to see if your obfs4 port is reachable from the Internet. +--- +subtitle: How to deploy obfs4proxy Bridge on OpenBSD +--- +section: Bridge +--- +section_id: bridge diff --git a/content/relay-operations/technical-setup/bridge/post-install/contents.lr b/content/relay-operations/technical-setup/bridge/post-install/contents.lr new file mode 100644 index 0000000..e7f19cd --- /dev/null +++ b/content/relay-operations/technical-setup/bridge/post-install/contents.lr @@ -0,0 +1,22 @@ +_model: page +--- +title: Post-install +--- +body: + +Congrats! If you get to this point, it means that your obfs4 bridge is running and is being distributed by BridgeDB to censored users. If you want to connect to your bridge manually, you will need to know the bridge's obfs4 certificate. See the file `/var/lib/tor/pt_state/obfs4_bridgeline.txt` and paste the entire bridge line into Tor Browser: + +``` +Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0 +``` + +You'll need to replace `<IP ADDRESS>`, `<PORT>`, and `<FINGERPRINT>` with the actual values, which you can find in the tor log. Make sure to use `<FINGERPRINT>`, not `<HASHED FINGERPRINT>`; and that `<PORT>` is the one from the log line `Registered server transport 'obfs4'`, not the one from the line `Now checking whether ORPort ... is reachable`. + +Finally, you can monitor your obfs4 bridge's usage on [Relay Search](https://metrics.torproject.org/rs.html#search). Just enter your bridge's `<HASHED FINGERPRINT>` in the form and click "Search". After having set up the bridge, it takes approximately three hours for the bridge to show up in Relay Search. + +--- +html: two-columns-page.html +--- +key: 5 +--- +subtitle: How to find your Bridge in Relay Search and connect manually diff --git a/content/relay-operations/technical-setup/centosrhel/contents.lr b/content/relay-operations/technical-setup/centosrhel/contents.lr deleted file mode 100644 index 28f5d71..0000000 --- a/content/relay-operations/technical-setup/centosrhel/contents.lr +++ /dev/null @@ -1,19 +0,0 @@ -_model: page ---- -title: CentOS ---- -html: two-columns-page.html ---- -section: relay operations ---- -section_id: relay-operations ---- -key: 3 ---- -body: - - ---- -subtitle: CentOS ---- -_slug: {{centos}} diff --git a/content/relay-operations/technical-setup/debianubuntu/contents.lr b/content/relay-operations/technical-setup/debianubuntu/contents.lr deleted file mode 100644 index 28f5d71..0000000 --- a/content/relay-operations/technical-setup/debianubuntu/contents.lr +++ /dev/null @@ -1,19 +0,0 @@ -_model: page ---- -title: CentOS ---- -html: two-columns-page.html ---- -section: relay operations ---- -section_id: relay-operations ---- -key: 3 ---- -body: - - ---- -subtitle: CentOS ---- -_slug: {{centos}} diff --git a/content/relay-operations/technical-setup/exit/contents.lr b/content/relay-operations/technical-setup/exit/contents.lr new file mode 100644 index 0000000..7c57eeb --- /dev/null +++ b/content/relay-operations/technical-setup/exit/contents.lr @@ -0,0 +1,181 @@ +_model: page +--- +title: Exit +--- +html: two-columns-page.html +--- +section: relay operations +--- +section_id: relay-operations +--- +key: 3 +--- +body: + +We assume you read through the [relay guide](..) already. This subpage is for operators that want to turn on exiting on their relay. + +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 turning your non-exit relay into an exit relay, ensure that you have set a reverse DNS record (PTR) to make it more obvious 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 + +## Exit Policy + +Defining the [exit policy](https://www.torproject.org/docs/tor-manual.html.en#ExitPolicy) is one of the most important parts of an exit relay configuration. +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 [ReducedExitPolicy](https://trac.torproject.org/projects/tor/wiki/doc/Reduce… wiki page. + +To become an exit relay change ExitRelay from 0 to 1 in your torrc configuration file and restart the tor daemon. + +``` +ExitRelay 1 +``` + +## 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 +``` + +--- +subtitle: How to deploy an Exit node +--- +_slug: {{exit}} diff --git a/content/relay-operations/technical-setup/fedora/contents.lr b/content/relay-operations/technical-setup/fedora/contents.lr deleted file mode 100644 index 9236220..0000000 --- a/content/relay-operations/technical-setup/fedora/contents.lr +++ /dev/null @@ -1,19 +0,0 @@ -_model: page ---- -title: Fedora ---- -html: two-columns-page.html ---- -section: relay operations ---- -section_id: relay-operations ---- -key: 3 ---- -body: - - ---- -subtitle: Fedora ---- -_slug: {{fedora}} diff --git a/content/relay-operations/technical-setup/freebsd/contents.lr b/content/relay-operations/technical-setup/freebsd/contents.lr deleted file mode 100644 index 28f5d71..0000000 --- a/content/relay-operations/technical-setup/freebsd/contents.lr +++ /dev/null @@ -1,19 +0,0 @@ -_model: page ---- -title: CentOS ---- -html: two-columns-page.html ---- -section: relay operations ---- -section_id: relay-operations ---- -key: 3 ---- -body: - - ---- -subtitle: CentOS ---- -_slug: {{centos}} diff --git a/content/relay-operations/technical-setup/guard/centosrhel/contents.lr b/content/relay-operations/technical-setup/guard/centosrhel/contents.lr new file mode 100644 index 0000000..27b6031 --- /dev/null +++ b/content/relay-operations/technical-setup/guard/centosrhel/contents.lr @@ -0,0 +1,56 @@ +_model: page +--- +title: CentOS/RHEL +--- +body: + +# 1. Enable the EPEL repository + +To install `tor` package on CentOS/RHEL, you need to install the [EPEL](https://fedoraproject.org/wiki/EPEL) repository first: + +`yum install epel-release` + +# 2. Install the tor package and verify the EPEL signing key + +`yum install tor` + +When you install the first package from the EPEL repository you will be asked about verifying the EPEL GPG signing key. Please ensure the key matches with the one available on the [Fedora Project website](https://getfedora.org/keys/). + +# 3. Put the tor configuration file `/etc/tor/torrc` in place + +``` +#change the nickname "myNiceRelay" to a name that you like +Nickname myNiceRelay +ORPort 9001 +SocksPort 0 +ExitRelay 0 +# Change the email address bellow and be aware that it will be published +ContactInfo tor-operator@your-emailaddress-domain +``` + +# 4. Enable and start your Tor relay + +CentOS 7 / RHEL 7: + +``` +systemctl enable tor +systemctl start tor +``` + +CentOS 6 / RHEL 6: + +``` +service tor enable +service tor start +``` + +--- +html: two-columns-page.html +--- +key: 5 +--- +section: relay operations +--- +section_id: relay-operations +--- +subtitle: How to deploy a middle/Guard node on CentOS/RHEL diff --git a/content/relay-operations/technical-setup/guard/contents.lr b/content/relay-operations/technical-setup/guard/contents.lr new file mode 100644 index 0000000..7cfa3dd --- /dev/null +++ b/content/relay-operations/technical-setup/guard/contents.lr @@ -0,0 +1,15 @@ +_model: page +--- +title: Middle/Guard relay +--- +body: In this guide we describe how to setup a new Middle/Guard relay. Please choose your platform below. +--- +html: two-columns-page.html +--- +key: 1 +--- +section: relay operations +--- +section_id: relay-operations +--- +subtitle: Run a Middle/Guard relay diff --git a/content/relay-operations/technical-setup/guard/debianubuntu/contents.lr b/content/relay-operations/technical-setup/guard/debianubuntu/contents.lr new file mode 100644 index 0000000..f7992dd --- /dev/null +++ b/content/relay-operations/technical-setup/guard/debianubuntu/contents.lr @@ -0,0 +1,46 @@ +_model: page +--- +title: Debian/Ubuntu +--- +body: + +# 1. Configure Tor Package Repository + +Enable the Torproject package repository by following the instructions **[here](https://2019.www.torproject.org/docs/debian.html.en#ubuntu)**. + +# 2. Package Installation + +Install the `tor` package: + +`apt update && apt install tor` + +# 3. Configuration File + +Put the configuration file `/etc/tor/torrc` in place: + +``` +#change the nickname "myNiceRelay" to a name that you like +Nickname myNiceRelay +ORPort 443 +ExitRelay 0 +SocksPort 0 +ControlSocket 0 +# Change the email address bellow and be aware that it will be published +ContactInfo tor-operator@your-emailaddress-domain +``` + +# 4. Restart the Service + +Restart the tor daemon so your configuration changes take effect: + +`systemctl restart tor@default` +--- +html: two-columns-page.html +--- +key: 1 +--- +section: relay operations +--- +section_id: relay-operations +--- +subtitle: How to deploy a middle/Guard node on Debian/Ubuntu diff --git a/content/relay-operations/technical-setup/guard/fedora/contents.lr b/content/relay-operations/technical-setup/guard/fedora/contents.lr new file mode 100644 index 0000000..cc984cc --- /dev/null +++ b/content/relay-operations/technical-setup/guard/fedora/contents.lr @@ -0,0 +1,37 @@ +_model: page +--- +title: Fedora +--- +body: + +# 1. Install the tor package: + +`dnf install tor` + +# 2. Put the tor configuration file `/etc/tor/torrc` in place: + +``` +#change the nickname "myNiceRelay" to a name that you like +Nickname myNiceRelay +ORPort 9001 +ExitRelay 0 +# Change the email address bellow and be aware that it will be published +ContactInfo tor-operator@your-emailaddress-domain +``` + +# 3. Start the tor daemon and make sure it starts at boot: + +``` +systemctl enable tor +systemctl start tor +``` +--- +html: two-columns-page.html +--- +key: 3 +--- +section: relay operations +--- +section_id: relay-operations +--- +subtitle: How to deploy a middle/Guard node on Fedora diff --git a/content/relay-operations/technical-setup/guard/freebsd/contents.lr b/content/relay-operations/technical-setup/guard/freebsd/contents.lr new file mode 100644 index 0000000..a47dfc8 --- /dev/null +++ b/content/relay-operations/technical-setup/guard/freebsd/contents.lr @@ -0,0 +1,73 @@ +_model: page +--- +title: FreeBSD +--- +body: + +## 1. Install the tor package + +`pkg install tor ca_root_nss` + +or for alpha releases: + +`pkg install tor-devel ca_root_nss` + +## 2. Put the configuration file `/usr/local/etc/tor/torrc` in place + +``` +#change the nickname "myNiceRelay" to a name that you like +Nickname myNiceRelay +ORPort 9001 +ExitRelay 0 +SocksPort 0 +# Change the email address bellow and be aware that it will be published +ContactInfo tor-operator@your-emailaddress-domain +Log notice syslog +``` + +## 3. Ensure that the `random_id` sysctl setting is enabled: + +``` +echo "net.inet.ip.random_id=1" >> /etc/sysctl.conf +sysctl net.inet.ip.random_id=1 +``` + +## 4. Start the tor daemon and make sure it starts at boot: + +``` +sysrc tor_enable=YES +service tor start +``` + +### Optional but recommended + +To get package updates faster after they have been build it is best to switch from the "quarterly" with "latest" repository. + +Create the following folder: + +`mkdir -p /usr/local/etc/pkg/repos` + +and create the file `/usr/local/etc/pkg/repos/FreeBSD.conf` with the following content: + +``` +FreeBSD: { enabled: no } + +FreeBSDlatest: { + url: "pkg+https://pkg.FreeBSD.org/${ABI}/latest", + mirror_type: "srv", + signature_type: "fingerprints", + fingerprints: "/usr/share/keys/pkg", + enabled: yes +} +``` + +--- +html: two-columns-page.html +--- +key: 2 +--- +section: relay operations +--- +section_id: relay-operations +--- +subtitle: How to deploy a middle/Guard node on FreeBSD diff --git a/content/relay-operations/technical-setup/post-install/contents.lr b/content/relay-operations/technical-setup/post-install/contents.lr new file mode 100644 index 0000000..5236fbe --- /dev/null +++ b/content/relay-operations/technical-setup/post-install/contents.lr @@ -0,0 +1,179 @@ +_model: page +--- +title: Relay Post-install and good practices +--- +body: + +#1. 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). + +# 2. 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. + +# 3. Read about 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). + +# 4. Configuration Management + +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 [Offline Master Keys](https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity/Of… 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: [Ansible Relayor](http://github.com/nusenu/ansible-relayor). + +# 5. 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](https://2019.www.torproject.org/docs/tor-manual.html.en#MyFamily) value and have a valid [ContactInfo](https://2019.www.torproject.org/docs/tor-manual.html.en#Contac… 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 are not used in multiple positions 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 configuration management solution. +Manually managing MyFamily for big relay groups is error prone and can put Tor clients at risk. + +# 6. Optional: 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). + +# 7. Check IPv6 availability + +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. + +# 8. 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: `/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: [tor-announce](https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-ann…. + +## 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](https://uptimerobot.com/) 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. + +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](http://munin-monitoring.org/) 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 lists a few tools that you might find handy as a Tor relay operator. + +* [Nyx](https://nyx.torproject.org/): 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](https://humdi.net/vnstat/) and [demo output](https://humdi.net/vnstat/cgidemo/). +--- +html: two-columns-page.html +--- +key: 4 +--- +section: Relay operations +--- +section_id: relay-operations +--- +subtitle:

1 0

[community/staging] Rename relay-operations slug to relay
by pili＠torproject.org 02 Aug '19

02 Aug '19

commit ed6fbda09c2f126bdf426d4470dcf41663047e7c Author: gus <gus(a)torproject.org> Date: Tue Jul 30 05:50:59 2019 -0400 Rename relay-operations slug to relay --- content/relay-operations/contents.lr | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/relay-operations/contents.lr b/content/relay-operations/contents.lr index f55c8ed..40f0df7 100644 --- a/content/relay-operations/contents.lr +++ b/content/relay-operations/contents.lr @@ -30,3 +30,5 @@ By running a Tor relay you can help make the Tor network: * safer for its users (spying on more relays is harder than on a few) Running a relay requires technical skill and commitment, which is why we've created a wealth of resources to help our relay operators. +--- +_slug: {{relay}}

1 0

[community/staging] Merge branch 'staging' of git-rw.torproject.org:project/web/community
by pili＠torproject.org 02 Aug '19

02 Aug '19

commit 45382eabc46ebcd67202e5befc10bd6b5e1d4836 Merge: a0e3e7e 02d7ea6 Author: Pili Guerra <pili(a)piliguerra.com> Date: Fri Aug 2 12:37:16 2019 +0100 Merge branch 'staging' of git-rw.torproject.org:project/web/community content/outreach/contents.lr | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

1 0

[community/staging] Remove speakers section
by pili＠torproject.org 02 Aug '19

02 Aug '19

commit a0e3e7e247620427eee5940525ce46ebf9acf3b9 Author: Pili Guerra <pili(a)piliguerra.com> Date: Fri Aug 2 10:58:12 2019 +0100 Remove speakers section --- content/outreach/contents.lr | 2 +- content/outreach/speakers/contents.lr | 19 ------------------- 2 files changed, 1 insertion(+), 20 deletions(-) diff --git a/content/outreach/contents.lr b/content/outreach/contents.lr index f18da38..40a16af 100644 --- a/content/outreach/contents.lr +++ b/content/outreach/contents.lr @@ -12,7 +12,7 @@ subtitle: Bring Tor materials to your next community event. --- cta: Tell the world about Tor --- -key: 3 +key: 2 --- html: outreach.html --- diff --git a/content/outreach/speakers/contents.lr b/content/outreach/speakers/contents.lr deleted file mode 100644 index 36e278d..0000000 --- a/content/outreach/speakers/contents.lr +++ /dev/null @@ -1,19 +0,0 @@ -section: outreach ---- -section_id: outreach ---- -color: primary ---- -_template: layout.html ---- -title: Speakers ---- -subtitle: Speakers ---- -key: 2 ---- -html: two-columns-page.html ---- -body: - -## Speakers

1 0

[community/staging] better strings for l10n
by pili＠torproject.org 02 Aug '19

02 Aug '19

commit 8dafac6672754e120e1a36721b735d1d45140108 Author: emma peel <emma.peel(a)riseup.net> Date: Wed Jul 31 18:14:09 2019 +0200 better strings for l10n --- content/onion-services/overview/contents.lr | 33 ++++++--- .../tor-relay-universities/contents.lr | 82 +++++++++++++++++----- .../technical-setup/exit/contents.lr | 6 +- 3 files changed, 91 insertions(+), 30 deletions(-) diff --git a/content/onion-services/overview/contents.lr b/content/onion-services/overview/contents.lr index 1974a0b..b8dd03f 100644 --- a/content/onion-services/overview/contents.lr +++ b/content/onion-services/overview/contents.lr @@ -63,39 +63,50 @@ As part of this step, Bob gives its introduction point a special "authentication Now that the introduction points are setup, we need to create a way for clients to be able to find them. -For this reason, Bob assembles an _onion service descriptor_, containing a list of his introduction points (and their "authentication keys"), and signs this descriptor with his _identity private key_. The _identity private key_ used here is the private part of the **public key that is encoded in the onion service address**. +For this reason, Bob assembles an _onion service descriptor_, containing a list of his introduction points (and their "authentication keys"), and signs this descriptor with his _identity private key_. +The _identity private key_ used here is the private part of the **public key that is encoded in the onion service address**. -Now, Bob uploads that signed descriptor to a _distributed hash table_ which is part of the Tor network, so that clients can also get it. Bob uses an anonymized Tor circuit to do this upload, so that he does not reveal his location. +Now, Bob uploads that signed descriptor to a _distributed hash table_ which is part of the Tor network, so that clients can also get it. +Bob uses an anonymized Tor circuit to do this upload, so that he does not reveal his location. ### Act 3: Where a client wants to visit the onion service -All the previous steps were just setup for the onion service so that it's reachable by clients. Now let's fast-forward to the point where an actual client wants to visit the service: +All the previous steps were just setup for the onion service so that it's reachable by clients. +Now let's fast-forward to the point where an actual client wants to visit the service: ![Onion Services: Step 3](/static/images/onion-services/overview/tor-onion-services-3.png) -In this case, Alice (the client) has the onion address of Bob and she wants to visit it, so she connects to it with her Tor Browser. Now the next thing that needs to happen is that Alice goes to the _distributed hash table_ from the step above, and ask for the signed descriptor of Bob. +In this case, Alice (the client) has the onion address of Bob and she wants to visit it, so she connects to it with her Tor Browser. +Now the next thing that needs to happen is that Alice goes to the _distributed hash table_ from the step above, and ask for the signed descriptor of Bob. -When Alice receives the signed descriptor she verifies the signature of the descriptor using the public key that is encoded in the onion address. This provides the _end-to-end authentication_ security property, since we are now sure that this descriptor could only be produced by Bob and no one else. And inside the descriptor there are the introduction points which allow Alice to introduce herself to Bob. +When Alice receives the signed descriptor she verifies the signature of the descriptor using the public key that is encoded in the onion address. +This provides the _end-to-end authentication_ security property, since we are now sure that this descriptor could only be produced by Bob and no one else. +And inside the descriptor there are the introduction points which allow Alice to introduce herself to Bob. ### Act 4: Where the client establishes a rendezvous point -Now before the introduction takes place, Alice picks a Tor relay and establishes a circuit to it. Alice asks the relay to become her _rendezvous point_ and gives it an "one-time secret" that will be used as part of the rendezvous procedure. +Now before the introduction takes place, Alice picks a Tor relay and establishes a circuit to it. +Alice asks the relay to become her _rendezvous point_ and gives it an "one-time secret" that will be used as part of the rendezvous procedure. ### Act 5: Where the client introduces itself to the onion service ![Onion Services: Step 4](/static/images/onion-services/overview/tor-onion-services-4.png) -Now, Alice goes ahead and connects to one of Bob's introduction points and introduces herself to Bob. Through this introduction Bob learns Alice's choice of rendezvous point and the "one-time secret". +Now, Alice goes ahead and connects to one of Bob's introduction points and introduces herself to Bob. +Through this introduction Bob learns Alice's choice of rendezvous point and the "one-time secret". ### Act 6: Where the onion service rendezvous with the client ![Onion Services: Step 5](/static/images/onion-services/overview/tor-onion-services-5.png) -In this last act, the onion service is now aware of Alice's rendezvous point. The onion service connects to the rendezvous point (through an anonymized circuit) and sends the "one-time secret" to it. +In this last act, the onion service is now aware of Alice's rendezvous point. +The onion service connects to the rendezvous point (through an anonymized circuit) and sends the "one-time secret" to it. -Upon the rendezvous point receiving the "one-time secret" from Bob, it informs Alice that the connection has been **successfuly completed**, and now Alice and Bob can use this circuit to communicate with each other. The rendezvous point simply relays (end-to-end encrypted) messages from client to service and vice versa. +Upon the rendezvous point receiving the "one-time secret" from Bob, it informs Alice that the connection has been **successfuly completed**, and now Alice and Bob can use this circuit to communicate with each other. +The rendezvous point simply relays (end-to-end encrypted) messages from client to service and vice versa. -In general, the complete connection between client and onion service consists of 6 relays: 3 of them were picked by the client with the third being the rendezvous point and the other 3 were picked by the onion service. This provides _location hiding_ to this connection: +In general, the complete connection between client and onion service consists of 6 relays: 3 of them were picked by the client with the third being the rendezvous point and the other 3 were picked by the onion service. +This provides _location hiding_ to this connection: ![Onion Services: Step 6](/static/images/onion-services/overview/tor-onion-services-6.png) @@ -109,4 +120,4 @@ https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt - Presentations about onion services https://www.youtube.com/watch?v=VmsFxBEN3fc -https://www.youtube.com/watch?v=Di7qAVidy1Y \ No newline at end of file +https://www.youtube.com/watch?v=Di7qAVidy1Y diff --git a/content/relay-operations/community-resources/tor-relay-universities/contents.lr b/content/relay-operations/community-resources/tor-relay-universities/contents.lr index 14040b8..6aba040 100644 --- a/content/relay-operations/community-resources/tor-relay-universities/contents.lr +++ b/content/relay-operations/community-resources/tor-relay-universities/contents.lr @@ -4,36 +4,86 @@ title: Tor Relay Universities --- body: -To keep your exit node running long-term, you're going to need the support of the people around you. In this sense, Tor provides a lever to help you change your organization's policies. If the administration considers an Internet community that helps other people to be a foreign concept, or if they're used to treating new situations as security risks and telling everybody to quit it, a Tor relay may give you a way to focus the discussion and find allies who want to help change policy. In short, running a Tor exit node may well require you to become an advocate for anonymity and privacy in the world. +To keep your exit node running long-term, you're going to need the support of the people around you. +In this sense, Tor provides a lever to help you change your organization's policies. +If the administration considers an Internet community that helps other people to be a foreign concept, or if they're used to treating new situations as security risks and telling everybody to quit it, a Tor relay may give you a way to focus the discussion and find allies who want to help change policy. +In short, running a Tor exit node may well require you to become an advocate for anonymity and privacy in the world. -The best strategy depends on your situation, but here are some tips to get you started. (We focus on the university scenario, but hopefully you can adapt it to your own situation.) +The best strategy depends on your situation, but here are some tips to get you started. +(We focus on the university scenario, but hopefully you can adapt it to your own situation.) - * First, learn about your university's AUP -- acceptable use policy. Most likely it is ambiguously worded, to let them allow or deny things based on the situation. But it might be extremely restrictive ("no services of any kind"), in which case you're going to have a tough road ahead of you. + * First, learn about your university's AUP -- acceptable use policy. +Most likely it is ambiguously worded, to let them allow or deny things based on the situation. +But it might be extremely restrictive ("no services of any kind"), in which case you're going to have a tough road ahead of you. - * Second, learn about your local laws with respect to liability of traffic that exits from your Tor relay. In the US, these appear to be mainly the [DMCA](https://2019.www.torproject.org/eff/tor-legal-faq.html#DMCA) and [CDA](https://2019.www.torproject.org/eff/tor-legal-faq.html#Lawsuits), and the good news is that many lawyers believe that Tor exit node operators are in the same boat as the ISPs themselves. Become familiar with -[the EFF's template letter regarding DMCA notices for Tor](https://2019.www.torproject.org/eff/tor-dmca-response.html), which is quite clear about not putting liability on service providers. The CDA is less clear, because it was written before the modern Internet emerged, but EFF and ACLU are optimistic. Of course, you need to understand that without actual clear precedent (and even then), it's still possible that a given judge will not interpret things the way the lawyers expect. In any case, the key here is to become familiar with the laws and their implications and uncertainties. + * Second, learn about your local laws with respect to liability of traffic that exits from your Tor relay. +In the US, these appear to be mainly the [DMCA](https://2019.www.torproject.org/eff/tor-legal-faq.html#DMCA) and [CDA](https://2019.www.torproject.org/eff/tor-legal-faq.html#Lawsuits), and the good news is that many lawyers believe that Tor exit node operators are in the same boat as the ISPs themselves. +Become familiar with [the EFF's template letter regarding DMCA notices for Tor](https://2019.www.torproject.org/eff/tor-dmca-response.html), which is quite clear about not putting liability on service providers. +The CDA is less clear, because it was written before the modern Internet emerged, but EFF and ACLU are optimistic. +Of course, you need to understand that without actual clear precedent (and even then), it's still possible that a given judge will not interpret things the way the lawyers expect. +In any case, the key here is to become familiar with the laws and their implications and uncertainties. - * Third, learn about Tor's design. Read the [design overview](https://2019.www.torproject.org/overview.html), the [design paper](https://www.torproject.org/svn/trunk/doc/design-paper/tor-design.htm…, and the FAQ. Hang out on IRC (irc.oftc.net - #tor-relays) for a while and learn more. If possible, attend a talk by one of the Tor developers. Learn about the types of people and organizations who need secure communications on the Internet. Practice explaining Tor and its benefits and consequences to friends and neighbors -- the [abuse FAQ](https://2019.www.torproject.org/faq-abuse) may provide some helpful starting points. + * Third, learn about Tor's design. +Read the [design overview](https://2019.www.torproject.org/overview.html), the [design paper](https://www.torproject.org/svn/trunk/doc/design-paper/tor-design.htm…, and the [FAQ](FIXME). +Hang out on IRC (irc.oftc.net - #tor-relays) for a while and learn more. +If possible, attend a talk by one of the Tor developers. +Learn about the types of people and organizations who need secure communications on the Internet. +Practice explaining Tor and its benefits and consequences to friends and neighbors -- the [abuse FAQ](https://2019.www.torproject.org/faq-abuse) may provide some helpful starting points. - * Fourth, learn a bit about authentication on the Internet. Many library-related services use source IP address to decide whether a subscriber is allowed to see their content. If the university's entire IP address space is "trusted" to access these library resources, the university is forced to maintain an iron grip on all its addresses. Universities like Harvard do the smart thing: their students and faculty have actual methods to authenticate -- say, certificates, or usernames and passwords -- to a central Harvard server and access the library resources from there. So Harvard doesn't need to be as worried about what other services are running on their network, and it also takes care of off-campus students and faculty. On the other hand, universities like Berkeley simply add a "no proxies" line to their network policies, and are stuck in a battle to patrol every address on their network. We should encourage all these networks to move to an end-to-end authentication model rather th an conflating network location with who's on the other end. + * Fourth, learn a bit about authentication on the Internet. +Many library-related services use source IP address to decide whether a subscriber is allowed to see their content. +If the university's entire IP address space is "trusted" to access these library resources, the university is forced to maintain an iron grip on all its addresses. +Universities like Harvard do the smart thing: their students and faculty have actual methods to authenticate -- say, certificates, or usernames and passwords -- to a central Harvard server and access the library resources from there. +So Harvard doesn't need to be as worried about what other services are running on their network, and it also takes care of off-campus students and faculty. +On the other hand, universities like Berkeley simply add a "no proxies" line to their network policies, and are stuck in a battle to patrol every address on their network. +We should encourage all these networks to move to an end-to-end authentication model rather than conflating network location with who's on the other end. - * Fifth, start finding allies. Find some professors (or deans!) who like the idea of supporting and/or researching anonymity on the Internet. If your school has a botnet research group or studies Internet attacks (like at Georgia Tech and UCSD), meet them and learn more about all the scary things already out there on the Internet. If you have a law school nearby, meet the professors that teach the Internet law classes, and chat with them about Tor and its implications. Ask for advice from everybody you meet who likes the idea, and try to work your way up the chain to get as many good allies as you can in as many areas as you can. + * Fifth, start finding allies. +Find some professors (or deans!) who like the idea of supporting and/or researching anonymity on the Internet. +If your school has a botnet research group or studies Internet attacks (like at Georgia Tech and UCSD), meet them and learn more about all the scary things already out there on the Internet. +If you have a law school nearby, meet the professors that teach the Internet law classes, and chat with them about Tor and its implications. +Ask for advice from everybody you meet who likes the idea, and try to work your way up the chain to get as many good allies as you can in as many areas as you can. - * Sixth, teach your university's lawyers about Tor. This may seem like a risky move, but it's way better for them to hear about Tor from you, in a relaxed environment, than to hear about it from a stranger over the phone. Remember that lawyers don't like being told how to interpret laws by a non-lawyer, but they are often pleased to hear that other lawyers have done a lot of the research and leg-work (this is where [the EFF's legal FAQ](https://2019.www.torproject.org/eff/tor-legal-faq) comes in, along with your law school contacts if you found any). Make sure to keep these discussions informal and small -- invite one of the general counsel out to coffee to discuss "something neat that may come up later on." Feel free to bring along one of the allies you found above, if it makes you more comfortable. Avoid having actual meetings or long email discussions, and make it clear that you don't need their official legal opinion yet. Remember that lawyers are paid to say no unless they hav e a reason to say yes, so when the time finally comes to ask their opinion on running a Tor exit node, make sure the question is not "are there any liability issues?", but rather "we'd like to do this, can you help us avoid the biggest issues?" Try to predict what they will say, and try to gain allies among the lawyers who like your cause and want to help. If they have concerns, or raise questions that you don't know how to answer, work with them to figure out the answers and make them happy. Becoming friends with the lawyers early in the process will avoid situations where they need to learn about everything and make a decision in one day. + * Sixth, teach your university's lawyers about Tor. +This may seem like a risky move, but it's way better for them to hear about Tor from you, in a relaxed environment, than to hear about it from a stranger over the phone. +Remember that lawyers don't like being told how to interpret laws by a non-lawyer, but they are often pleased to hear that other lawyers have done a lot of the research and leg-work (this is where [the EFF's legal FAQ](https://2019.www.torproject.org/eff/tor-legal-faq) comes in, along with your law school contacts if you found any). +Make sure to keep these discussions informal and small -- invite one of the general counsel out to coffee to discuss "something neat that may come up later on." Feel free to bring along one of the allies you found above, if it makes you more comfortable. +Avoid having actual meetings or long email discussions, and make it clear that you don't need their official legal opinion yet. +Remember that lawyers are paid to say no unless they have a reason to say yes, so when the time finally comes to ask their opinion on running a Tor exit node, make sure the question is not "are there any liability issues?", but rather "we'd like to do this, can you help us avoid the biggest issues?" Try to predict what they will say, and try to gain allies among the lawyers who like your cause and want to help. +If they have concerns, or raise questions that you don't know how to answer, work with them to figure out the answers and make them happy. +Becoming friends with the lawyers early in the process will avoid situations where they need to learn about everything and make a decision in one day. - * Seventh, teach your network security people about Tor. You aren't going to keep your Tor exit node a secret from them for long anyway, and like with the lawyers, hearing it from you is way better than hearing it from a stranger on the phone. Avoid putting them on the spot or formally asking permission: most network security people will like the idea of Tor in theory, but they won't be in a position to "authorize" your Tor relay. Take them out to coffee to explain Tor and let them know that you are planning to run a Tor server. Make it clear that you're willing to work with them to make sure it isn't too much hassle on their part; for example, they can pass complaints directly on to you if they like. These people are already overworked, and anything you can do to keep work off their plate will make everybody happier. You might let them know that there are ways you can dial down the potential for abuse complaints, for example by rate limiting or partially restricting your exit poli cy -- but don't be too eager to offer or take these steps, since once you give up ground here it's very hard to get it back. + * Seventh, teach your network security people about Tor. +You aren't going to keep your Tor exit node a secret from them for long anyway, and like with the lawyers, hearing it from you is way better than hearing it from a stranger on the phone. +Avoid putting them on the spot or formally asking permission: most network security people will like the idea of Tor in theory, but they won't be in a position to "authorize" your Tor relay. +Take them out to coffee to explain Tor and let them know that you are planning to run a Tor server. +Make it clear that you're willing to work with them to make sure it isn't too much hassle on their part; for example, they can pass complaints directly on to you if they like. +These people are already overworked, and anything you can do to keep work off their plate will make everybody happier. +You might let them know that there are ways you can dial down the potential for abuse complaints, for example by rate limiting or partially restricting your exit policy -- but don't be too eager to offer or take these steps, since once you give up ground here it's very hard to get it back. -You'll also want to learn if there are bandwidth limitations at your organization. (Tor can handle a variety of rate limiting approaches, so this isn't the end of the world). +You'll also want to learn if there are bandwidth limitations at your organization. +(Tor can handle a variety of rate limiting approaches, so this isn't the end of the world). -In some cases, you should talk to the network security people before you talk to the lawyers; in some cases, there will be yet other groups that will be critical to educate and bring into the discussion. You'll have to make it up as you go. +In some cases, you should talk to the network security people before you talk to the lawyers; in some cases, there will be yet other groups that will be critical to educate and bring into the discussion. +You'll have to make it up as you go. -If the authorities contact your university for logs, be pleasant and helpful. Tor's default log level doesn't provide much that's useful, so if they want copies of your logs, that's fine. Be helpful and take the opportunity to explain to them about Tor and why it's useful to the world. (If they contact you directly for logs, you should send them to +If the authorities contact your university for logs, be pleasant and helpful. +Tor's default log level doesn't provide much that's useful, so if they want copies of your logs, that's fine. +Be helpful and take the opportunity to explain to them about Tor and why it's useful to the world. +(If they contact you directly for logs, you should send them to your university's lawyers -- acting on it yourself is [almost always a poor idea](https://2019.www.torproject.org/eff/tor-legal-faq.html#RequestForLogs). -If there are too many complaints coming in, there are several approaches you can take to reduce them. First, you should follow the tips in the [Tor relay documentation](https://community.torproject.org/relay-operations), such -as picking a descriptive hostname or getting your own IP address. If that doesn't work, you can scale back the advertised speed of your relay, by using the Max``Advertised``Bandwidth to attract less traffic from the Tor network. Lastly, you can scale back your exit policy. +If there are too many complaints coming in, there are several approaches you can take to reduce them. +First, you should follow the tips in the [Tor relay documentation](https://community.torproject.org/relay-operations), such +as picking a descriptive hostname or getting your own IP address. +If that doesn't work, you can scale back the advertised speed of your relay, by using the Max``Advertised``Bandwidth to attract less traffic from the Tor network. +Lastly, you can scale back your exit policy. -Some people have found that their university only tolerates their Tor relay if they're involved in a research project around anonymity. So if you're interested, you might want to get that started early in the process -- see our [Research Portal](https://research.torproject.org/). This approach has the added benefit that you can draw in other faculty and students in the process. The downside is that your Tor relay's existence is more fragile, since the terms of its demise are already negotiated. Note that in many cases you don't even need to be researching the exit node itself -- doing research on the Tor network requires that there be a Tor network, after all, and keeping it going is a community effort. +Some people have found that their university only tolerates their Tor relay if they're involved in a research project around anonymity. +So if you're interested, you might want to get that started early in the process -- see our [Research Portal](https://research.torproject.org/). +This approach has the added benefit that you can draw in other faculty and students in the process. +The downside is that your Tor relay's existence is more fragile, since the terms of its demise are already negotiated. +Note that in many cases you don't even need to be researching the exit node itself -- doing research on the Tor network requires that there be a Tor network, after all, and keeping it going is a community effort. Subscribe to [Tor Relays Universities](https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-rel… mailing list (and other education institutions too). --- diff --git a/content/relay-operations/technical-setup/exit/contents.lr b/content/relay-operations/technical-setup/exit/contents.lr index 7c57eeb..ee0148c 100644 --- a/content/relay-operations/technical-setup/exit/contents.lr +++ b/content/relay-operations/technical-setup/exit/contents.lr @@ -66,9 +66,9 @@ DNS resolution on exit relays is crucial for Tor clients, it should be reliable 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) + * 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).

1 0

[community/staging] this section is not needed
by pili＠torproject.org 02 Aug '19

02 Aug '19

commit 26f24f9f4509e1f3fb1ed389b6aca2fbb3a58c37 Author: emma peel <emma.peel(a)riseup.net> Date: Wed Jul 31 18:39:21 2019 +0200 this section is not needed --- content/localization/translate-strings/contents.lr | 19 ------------------- 1 file changed, 19 deletions(-) diff --git a/content/localization/translate-strings/contents.lr b/content/localization/translate-strings/contents.lr deleted file mode 100644 index 6f88833..0000000 --- a/content/localization/translate-strings/contents.lr +++ /dev/null @@ -1,19 +0,0 @@ -section: localization ---- -section_id: localization ---- -color: primary ---- -_template: layout.html ---- -title: Translate strings ---- -subtitle: How to translates ---- -key: 4 ---- -html: two-columns-page.html ---- -body: - -### How to translates

1 0

[community/staging] Move middle-guard setup to child page
by pili＠torproject.org 02 Aug '19

02 Aug '19

commit 95fdd883f43dca9e7ca42acb44cc489ab4a41e30 Author: gus <gus(a)torproject.org> Date: Fri Jul 5 15:29:47 2019 -0400 Move middle-guard setup to child page --- .../technical-setup/centosrhel/contents.lr | 58 ----------------- .../technical-setup/debianubuntu/contents.lr | 44 ------------- .../technical-setup/fedora/contents.lr | 37 ----------- .../technical-setup/freebsd/contents.lr | 75 ---------------------- 4 files changed, 214 deletions(-) diff --git a/content/relay-operations/technical-setup/centosrhel/contents.lr b/content/relay-operations/technical-setup/centosrhel/contents.lr deleted file mode 100644 index e8a9a51..0000000 --- a/content/relay-operations/technical-setup/centosrhel/contents.lr +++ /dev/null @@ -1,58 +0,0 @@ -_model: page ---- -title: CentOS/RHEL ---- -html: two-columns-page.html ---- -section: relay operations ---- -key: 5 ---- -section_id: relay-operations ---- -body: - -# 1. Enable the EPEL repository - -To install `tor` package on CentOS/RHEL, you need to install the [EPEL](https://fedoraproject.org/wiki/EPEL) repository first: - -`yum install epel-release` - -# 2. Install the tor package and verify the EPEL signing key - -`yum install tor` - -When you install the first package from the EPEL repository you will be asked about verifying the EPEL GPG signing key. Please ensure the key matches with the one available on the [Fedora Project website](https://getfedora.org/keys/). - -# 3. Put the tor configuration file `/etc/tor/torrc` in place - -``` -#change the nickname "myNiceRelay" to a name that you like -Nickname myNiceRelay -ORPort 9001 -SocksPort 0 -ExitRelay 0 -# Change the email address bellow and be aware that it will be published -ContactInfo tor-operator@your-emailaddress-domain -``` - -# 4. Enable and start your Tor relay - -CentOS 7 / RHEL 7: - -``` -systemctl enable tor -systemctl start tor -``` - -CentOS 6 / RHEL 6: - -``` -service tor enable -service tor start -``` - ---- -_template: layout.html ---- -color: primary diff --git a/content/relay-operations/technical-setup/debianubuntu/contents.lr b/content/relay-operations/technical-setup/debianubuntu/contents.lr deleted file mode 100644 index 79c652e..0000000 --- a/content/relay-operations/technical-setup/debianubuntu/contents.lr +++ /dev/null @@ -1,44 +0,0 @@ -_model: page ---- -title: Debian/Ubuntu ---- -html: two-columns-page.html ---- -section: relay operations ---- -section_id: relay-operations ---- -key: 2 ---- -body: - -# 1. Configure Tor Package Repository - -Enable the Torproject package repository by following the instructions **[here](https://2019.www.torproject.org/docs/debian.html.en#ubuntu)**. - -# 2. Package Installation - -Install the `tor` package: - -`apt update && apt install tor` - -# 3. Configuration File - -Put the configuration file `/etc/tor/torrc` in place: - -``` -#change the nickname "myNiceRelay" to a name that you like -Nickname myNiceRelay -ORPort 443 -ExitRelay 0 -SocksPort 0 -ControlSocket 0 -# Change the email address bellow and be aware that it will be published -ContactInfo tor-operator@your-emailaddress-domain -``` - -# 4. Restart the Service - -Restart the tor daemon so your configuration changes take effect: - -`systemctl restart tor@default` diff --git a/content/relay-operations/technical-setup/fedora/contents.lr b/content/relay-operations/technical-setup/fedora/contents.lr deleted file mode 100644 index 0a561f8..0000000 --- a/content/relay-operations/technical-setup/fedora/contents.lr +++ /dev/null @@ -1,37 +0,0 @@ -_model: page ---- -title: Fedora ---- -html: two-columns-page.html ---- -key: 3 ---- -section: relay operations ---- -section_id: relay-operations ---- -_template: layout.html ---- -body: - -# 1. Install the tor package: - -`dnf install tor` - -# 2. Put the tor configuration file `/etc/tor/torrc` in place: - -``` -#change the nickname "myNiceRelay" to a name that you like -Nickname myNiceRelay -ORPort 9001 -ExitRelay 0 -# Change the email address bellow and be aware that it will be published -ContactInfo tor-operator@your-emailaddress-domain -``` - -# 3. Start the tor daemon and make sure it starts at boot: - -``` -systemctl enable tor -systemctl start tor -``` diff --git a/content/relay-operations/technical-setup/freebsd/contents.lr b/content/relay-operations/technical-setup/freebsd/contents.lr deleted file mode 100644 index 3323fd5..0000000 --- a/content/relay-operations/technical-setup/freebsd/contents.lr +++ /dev/null @@ -1,75 +0,0 @@ -_model: page ---- -title: FreeBSD ---- -html: two-columns-page.html ---- -section: relay operations ---- -key: 2 ---- -section_id: relay-operations ---- -body: - -## 1. Install the tor package - -`pkg install tor ca_root_nss` - -or for alpha releases: - -`pkg install tor-devel ca_root_nss` - -## 2. Put the configuration file `/usr/local/etc/tor/torrc` in place - -``` -#change the nickname "myNiceRelay" to a name that you like -Nickname myNiceRelay -ORPort 9001 -ExitRelay 0 -SocksPort 0 -# Change the email address bellow and be aware that it will be published -ContactInfo tor-operator@your-emailaddress-domain -Log notice syslog -``` - -## 3. Ensure that the `random_id` sysctl setting is enabled: - -``` -echo "net.inet.ip.random_id=1" >> /etc/sysctl.conf -sysctl net.inet.ip.random_id=1 -``` - -## 4. Start the tor daemon and make sure it starts at boot: - -``` -sysrc tor_enable=YES -service tor start -``` - -### Optional but recommended - -To get package updates faster after they have been build it is best to switch from the "quarterly" with "latest" repository. - -Create the following folder: - -`mkdir -p /usr/local/etc/pkg/repos` - -and create the file `/usr/local/etc/pkg/repos/FreeBSD.conf` with the following content: - -``` -FreeBSD: { enabled: no } - -FreeBSDlatest: { - url: "pkg+https://pkg.FreeBSD.org/${ABI}/latest", - mirror_type: "srv", - signature_type: "fingerprints", - fingerprints: "/usr/share/keys/pkg", - enabled: yes -} -``` - ---- -_template: layout.html ---- -color:

1 0

[community/staging] Import Good US ISPs from trac to good-bad-isps page
by pili＠torproject.org 02 Aug '19

02 Aug '19

commit 5e5bd27ec3db76103111ae7d850c904f066ebc01 Author: gus <gus(a)torproject.org> Date: Fri Jul 5 18:27:07 2019 -0400 Import Good US ISPs from trac to good-bad-isps page --- .../community-resources/good-bad-isps/contents.lr | 68 ++++++++++++++++------ 1 file changed, 51 insertions(+), 17 deletions(-) diff --git a/content/relay-operations/community-resources/good-bad-isps/contents.lr b/content/relay-operations/community-resources/good-bad-isps/contents.lr index 5f614e0..7384bc1 100644 --- a/content/relay-operations/community-resources/good-bad-isps/contents.lr +++ b/content/relay-operations/community-resources/good-bad-isps/contents.lr @@ -8,30 +8,64 @@ This page aims to list community experiences with Tor and various Internet Servi Be sure to provide useful information like how much bandwidth you pushed, whether you thought the deal was cheap or expensive, how hard you had to work to make them understand what's going on, how long your server has been running, and whether you'd recommend them to others. Also include dates. -Since non-exits do not attract complaints, it should be fine to run them without contacting the hoster first. Make sure you understand their policies regarding bandwidth, especially on "unlimited" (fair use) contracts. For exit relays, you should read the fine Tor Exit Guidelines first. +Since non-exits do not attract complaints, it should be fine to run them without contacting the hoster first. Make sure you understand their policies regarding bandwidth, especially on "unlimited" (fair use) contracts. For exit relays, you should read the fine [Tor Exit Guidelines](tor-exit-guidelines) first. -For network diversity and stronger anonymity, you should avoid providers and countries that already attract a lot of Tor capacity. [metrics](https://metrics.torproject.org/) is a great tool that allows you to group probabilities by country and AS (autonomous systems), so you can more easily identify networks you want to avoid. +For network diversity and stronger anonymity, you should avoid providers and countries that already attract a lot of Tor capacity. [Metrics](https://metrics.torproject.org/) is a great tool that allows you to group probabilities by country and AS (autonomous systems), so you can more easily identify networks you want to avoid. **Note**: This page is currently being revamped. If you would like to help out please see [#31063](https://trac.torproject.org/projects/tor/ticket/31063). -## Proposed ISPs +# Good Experiences + +## US + +| **Company/ISP** | **ASN** | **Bridges** | **Relay** | **Exit** | **Comments** | **Last Updated** | +|-------------------------|-------------|-----------------|--------------|-------------|---------------------|------------------------| +| [2HOST](https://2host.com/) | - | Yes | Yes | Yes(?) | Vague AUP/Abuse handling | 10/15/14 | +| [Amazon Web Services (AWS)](https://aws.amazon.com) | - | Yes | Yes | No | - | - | +| [AmeriNOC](https://www.amerinoc.com/) | - | Yes | Yes | Yes | - | - | +| [Arvixe](https://www.arvixe.com/vps_virtual_private_servers_hosting/) | - | Yes | Yes | Yes | - | 06/19/13 | +| [Axigy](http://www.axigy.com) | - | Yes | Yes | Yes | - | - | +| [Blacklotus](http://www.blacklotus.net) | - | Yes | Yes | Yes | Liberal abuse handling policies | - | +| [BuyVM.net](https://buyvm.net) | AS53667 | Yes | Yes | Yes | New Tor rules [here](https://buyvm.net/acceptable-use-policy/#3). All relays are fine if you follow the steps. | - | +| [Catalyst Host](https://catalysthost.com/) | - | ? | No | No | "If you are interested in hosting either, you can ask us about a dedicated server." | 10/01/14 | +| [ChunkHost](http://chunkhost.com) | - | Yes | Yes | ? | Questionable DMCA handling | 01/01/12 | +| [Cyberonic](http://www.cyberonic.com) | - | Yes | Yes | ? | - | - | +| [Datawagon](https://datawagon.net) | AS27176 | Yes | Yes | Yes | Customers are forwarded abuse complaints to handle themselves | 03/06/19 | +| [DreamHost](https://www.dreamhost.com/) | - | Yes | Yes | ? | - | 11/29/17 | +| [Ethr.net](http://ethr.net/) | - | Yes | Yes | Yes | - | - | +| [Evolucix](http://www.evolucix.com) | - | Yes | Yes | No(?) | - | - | +| [Future Hosting](http://www.futurehosting.com/) | - | Yes | Yes | No | - | 09/01/14 | +| [HostGator](http://www.hostgator.com/) | - | No | No | No | - | - | +| [HostHatch](https://hosthatch.com) | AS46562 | Yes | Yes | No | Their vps isp are mixed include: QuadraNet, nLayer, AboveNet, Inteliquent, Atrato Networks and open peering with the entire Any2LA and Atlanta TIE networks. | 05/01/16 | +| [HostUS](http://hostus.us/) | AS25926 | Yes | Yes | No | - | 10/16/14 | +| [IPXcore](https://ipxcore.com/) | - | Yes | Yes | No | - | +| [Luna Node](https://www.lunanode.com/index.php) | - | Yes | Yes | No | - | 05/01/14 | +| [OVH](https://www.ovh.com/us/index.xml ) | AS16276 | Yes | Yes | ? | - | 12/31/14 | +| [Oplink.net](https://www.oplink.net) | - | Yes | Yes | No | - | 09/03/15 | +| [Psychz.net](https://www.psychz.net/) | - | Yes | Yes | Yes | Very Exit friendly. Standard Tor response will resolve abuse issues. | 10/07/15 | +| [PulseServers](https://www.pulseservers.com) | AS16276 | Yes | Yes | Yes | Exit-friendly. | 05/01/16 | +| [RamNode](http://ramnode.com/) | AS3842 | Yes | Yes | No | - | 11/03/14 | +| [Server Complete](https://servercomplete.com/) | - | ? | ? | No | - | 11/03/14 | +| [Softlayer](http://www.softlayer.com) | - | Yes | Yes | ? | - | - | +| [Slicehost/Rackspace](http://www.slicehost.com/) | - | Yes | Yes | No | Host, not an ISP | - | +| [Sh3lls](http://www.sh3lls.net/dedicated.htm) | - | Yes | Yes | No | - | - | +| [SolarVPS](https://solarvps.com) | - | Yes | Yes | Yes | - | - | +| [SeedVPS](https://www.seedvps.com) | - | Yes | Yes | No | - | - | +| [Tailored VPS](http://tailoredvps.com/) | - | Yes | Yes | Yes(?) | - | - | +| [VPS6.NET](https://vps6.net/) | - | Yes | Yes | No | - | - | +| [VPSWebServer.com](http://www.vpswebserver.com) | - | Yes || No | ? | - | - | +| [Inerail](http://inerail.net/) | - | Yes | Yes | Yes | Tor only allowed on dedicated/colocation | - | +| [CondoInternet ISP](http://www.condointernet.net/) | - | Yes | Yes | Yes | - | - | +| [DigitalOcean](http://digitalocean.com/) | - | Yes | Yes | No | - | - | +| [PhoenixNap / Secured Servers](http://www.phoenixnap.com/) | - | Yes | Yes | No | - | 08/01/14 | +| [Vultr](http://vultr.com) | AS20473 | Yes | Yes | No | When asked directly they will claim they do support Tor exits but will pull the rug out from under you later on. This has happened to at least two exit operators. | - | +| [ChicagoVPS](http://chicagovps.net/) | - | Yes | Yes | No | Tor bridge/relay is allowed on the whole VPS range. Any VPS running Exit nodes will be suspended without prior notice. | 15/01/15 | +| [Xmission](https://www.xmission.com/) | - | Yes | Yes | Yes | - | 01/28/15 | +| [blackpulsehosting](https://www.blackpulsehosting.com) | - | Yes | Yes | No | - | 10/25/15 | +| [MonkeyBrains](https://monkeybrains.net) | AS32329 | Yes | Yes | Yes | Only offers colocation, no cheap VPS option. | 1/14/19 | -The table below contains some community-suggested ISPs which have yet to be contacted and/or evaluated on their policies towards Tor hosting of any kind. If you have seen a host and would like to suggest it to us, but do not have the time or confidence to reach out, please do leave their website information below. -| **Company/ISP** | **Website** | **Language** | **Tasked?** | **Comments** | -|-------------------------|------------------|--------------------|------------------|---------------------| -| [Evolution Host VPS](https://evolution-host.com/vps-hosting.php) | [Evolution Host](https://evolution-host.com/) | English | https://evolution-host.com/tos.php | "No problem at all! We certainly aren't against the use of Tor on our services. You may host any type of Tor node." | -| QuickPacket | quickpacket.com | English | ToS prohibit "any activity" related to Tor as of 2015-03-31. See prohibited use 22 http://quickpacket.com/tos.html | -| Delimiter | delimiter.com | English | https://www.delimiter.com/terms-conditions/ | -| Reliable Hosting | reliablehosting.com | English | 2015-12-31 "Sorry, we don't allow Tor exit node on our servers" | -| Dacentec | dacentec.com | English | 2015-12-29 Dacentec Support: "Tor Nodes are prohibited by our terms of service and acceptable use policy. 2 sites were given https://billing.dacentec.com/hostbill/aup.php and https://billing.dacentec.com/hostbill/terms.php | -| Joe's Datacenter | joesdatacenter.com | English | | "For abuse complaints, if we receive them while your account is still fairly new, we automatically terminate services." | -| Wholesale Internet | wholesaleinternet.com | English | 2015-12-29 Wholesale Internet sales:"We do not block traffic, but you must respond to all abuse reports within 24 hours." | Core2Duo Dedi 100Mbit connection serves only ~ 35 Mbit (1/5/16)| -| Datashack.net \\ ASN: AS33387 | datashack.net | English | 2015-11-21 DataShack Sales: "We do not appose TOR, but require to respond to all abuse reports within 24 hours." | -| !CrownCloud | crowncloud.net | English | ~~ToS dis-allow bridge, relay, or exit as of 2015-03-31.~~ As of 2015-07-22, only exits are disallowed. Entry, bridge and middle are fine. See item 17 at http://wiki.crowncloud.net/doku.php/vps_tos | -| Deepnet Solutions | deepnetsolutions.com | English | They specifically allow Tor relays (not exits) on their dedicated IPV4 VPSs NOT on any NAT or OHM packages. \\ Some of their locations have a lot of consensus weight (AS12876 and AS16276), maybe not so good for diversity. | -| Andrews & Arnold | aa.net.uk | English | UK. IPv6. Note: Very very pro-privacy, has made public their net freedom and anti-surveillance stance. Zero censorship. | --- html: two-columns-page.html

1 0

[community/staging] Merge branch 'relays' into 'master'
by pili＠torproject.org 02 Aug '19

02 Aug '19

commit b9ecab71dbffba433c46f1c264235592be7b61df Merge: 95ba41c 9f08fa9 Author: gus <gus(a)riseup.net> Date: Fri Jul 5 07:50:48 2019 -0700 Merge branch 'relays' into 'master' Relay Operations: Technical Considerations, Technical Setup, Community Resources See merge request gus/communitytpo!1 .../community-resources/contents.lr | 58 ++- .../community-resources/good-bad-isps/contents.lr | 45 +++ .../tor-abuse-templates/contents.lr | 302 ++++++++++++++ .../tor-exit-guidelines/contents.lr | 117 ++++++ .../tor-relay-universities/contents.lr | 49 +++ content/relay-operations/contents.lr | 2 +- .../relays-requirements/contents.lr | 6 +- .../technical-considerations/contents.lr | 95 +++++ .../centos-rhel-opensuse/contents.lr | 101 +++++ .../bridge-deployment-guide/contents.lr | 23 ++ .../debian-ubuntu/contents.lr | 80 ++++ .../bridge-deployment-guide/freebsd/contents.lr | 98 +++++ .../bridge-deployment-guide/openbsd/contents.lr | 74 ++++ .../post-install/contents.lr | 22 + .../technical-setup/centosrhel/contents.lr | 45 +++ .../relay-operations/technical-setup/contents.lr | 444 +-------------------- .../technical-setup/exit-relay/contents.lr | 8 +- .../technical-setup/fedora/contents.lr | 26 ++ .../technical-setup/freebsd/contents.lr | 66 ++- .../middleguard-relay/centosrhel/contents.lr | 56 +++ .../technical-setup/middleguard-relay/contents.lr | 15 + .../middleguard-relay/debianubuntu/contents.lr | 46 +++ .../middleguard-relay/fedora/contents.lr | 37 ++ .../middleguard-relay/freebsd/contents.lr | 73 ++++ .../contents.lr | 175 ++++++++ .../relay-operations/types-of-relays/contents.lr | 5 +- 26 files changed, 1618 insertions(+), 450 deletions(-)

1 0

[community/staging] Update and fix broken links in community resources section
by pili＠torproject.org 02 Aug '19

02 Aug '19

commit 8b84468779ffac746b2e4c81bf8717e867d69181 Author: gus <gus(a)torproject.org> Date: Fri Jul 5 18:26:03 2019 -0400 Update and fix broken links in community resources section --- content/relay-operations/community-resources/contents.lr | 4 ++-- .../community-resources/tor-abuse-templates/contents.lr | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/relay-operations/community-resources/contents.lr b/content/relay-operations/community-resources/contents.lr index e6be9c0..eb905fc 100644 --- a/content/relay-operations/community-resources/contents.lr +++ b/content/relay-operations/community-resources/contents.lr @@ -33,7 +33,7 @@ It is important to respond to abuse complaints in a timely manner (usually withi Other docs we like: * a letter Boing Boing used to respond to a US federal subpoena about their exit relay: [What happened when we got subpoenaed over our Tor exit node](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: [DMCA Template](https://github.com/coldhakca/abuse-templates/blob/master/dmca.tem…, [Genetic Abuse Template](https://github.com/coldhakca/abuse-templates/blob/master/generic.…. +* abuse response templates from Coldhak, an organization in Canada that runs multiple relays: [DMCA Template](https://github.com/coldhakca/abuse-templates/blob/master/dmca.tem…, [Generic Abuse Template](https://github.com/coldhakca/abuse-templates/blob/master/generic.…. # Running a relay with other people @@ -63,5 +63,5 @@ Congratulations, you're officially a Tor relay operator! What now? * There is also more info about running a relay at the [Tor FAQ](https://2019.www.torproject.org/docs/faq.html.en#HowDoIDecide). -* And, most importantly, make sure to email tshirt(a)torproject.org and [claim your swag](https://2019.www.torproject.org/getinvolved/tshirt.html). It's our way of saying thanks for defending privacy and free speech online. +* And, most importantly, make sure to email tshirt(a)torproject.org and [claim your swag](swags). It's our way of saying thanks for defending privacy and free speech online. diff --git a/content/relay-operations/community-resources/tor-abuse-templates/contents.lr b/content/relay-operations/community-resources/tor-abuse-templates/contents.lr index f9952e6..e57afb2 100644 --- a/content/relay-operations/community-resources/tor-abuse-templates/contents.lr +++ b/content/relay-operations/community-resources/tor-abuse-templates/contents.lr @@ -6,7 +6,7 @@ body: # Before You Start -The best way to handle abuse complaints is to set up your exit node so that they are less likely to be sent in the first place. Please see [Tips for Running an Exit Node with Minimal Harassment](https://blog.torproject.org/running-exit-node) and [Tor Exit Guidelines](/tor-exit-guidelines) for more info, before reading this document. +The best way to handle abuse complaints is to set up your exit node so that they are less likely to be sent in the first place. Please see [Tips for Running an Exit Node with Minimal Harassment](https://blog.torproject.org/running-exit-node) and [Tor Exit Guidelines](tor-exit-guidelines) for more info, before reading this document. Below are a collection of letters you can use to respond to your ISP about their complaint in regards to your Tor exit server.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits August 2019