- tor-relays - lists.torproject.org

Relay operator section in our forum
by Georg Koppen 21 Dec '21

21 Dec '21

Hello! Some of you might already have seen that we have a shiny new forum now.[1] And, of course, there is a part of it dedicated to providing support for relay operators as well.[2] Check it out and feel free to contribute! Thanks, Georg [1] https://forum.torproject.net/ [2] https://forum.torproject.net/c/support/relay-operator/17

5 7

Running dedicated Tor node hosting
by bobby stickel 20 Dec '21

20 Dec '21

3 3

Middle Relay shows Adv. Bandwidth of 0 B on Tor-Metrics
by petrarca＠protonmail.ch 19 Dec '21

19 Dec '21

My middle relay 605EE4375EE4C38215C8949F5808863749FD4F4A crashed and I had to set it up from scratch. It's up again for over 14 hours now, and all logs and other checks I did look fine - the only thing which is strange is on the Tor-Metrics page showing "Advertised Bandwidth" as zero (0 B). Any idea what I might have missed or overlooked?

1 0

Introduction from lokodlare
by abuse＠lokodlare.com 16 Dec '21

16 Dec '21

Hello Tor relay operators, I joined this mail list recently and wanted to take the opportunity to shortly introduce myself. My name is Kristian, I am based in Europe, and I operate all nodes behind the domain lokodlare.com. “Lökodlare” is Swedish for “onion farmers”, which is pretty much what I do. My goal is to contribute to the Tor network by providing a couple of high-bandwidth nodes all over the globe, preferably at less common providers and/or in niche countries. I will focus on Middle and Guard relays, though I will throw some exits into the mix every now and then with a very reduced exit policy. I currently operate 90+ relays and bridges with a theoretical bandwidth capacity of roughly 25 Gbit/s. As a snapshot, those nodes handled around 280 TB of Tor-related traffic in the past 24 hours. I am looking forward to talk/discuss with all of you in the future. Thanks, have a great Sunday, Kristian

4 7

IPv6
by xplato 16 Dec '21

16 Dec '21

Hi all, I was able to add IPv6 on four HardenedBSD relays I run however I have now noticed a number of malicious login attempts. I am wondering if there is some correlation with the IPv6 or just a coincidence? Best regards, Dan Sent from ProtonMail for iOS

3 2

Old question
by Qimam Fellowship 16 Dec '21

16 Dec '21

Hello, the Torproject. We launched relays and bridges 3 days ago, today we received a few emails from noreply(a)torweather.org saying that our relays are down. Your metrics website says our relays are offline, but in fact our VPS are online and tor daemon is running. The status of our bridges is displayed as online. We attached tor daemon log from one of our relays and list of our relays and bridges fingerprint. Is this an error on your metrics website and Tor Weather bot or we misconfigured something?

3 6

How to become a directory authority
by bobby stickel 16 Dec '21

16 Dec '21

2 1

Tor not starting but log inconclusive
by yl 15 Dec '21

15 Dec '21

Hello all, I have a problem with a Tor Exit. Tor will not start correctly, but there is nothing in the logs. Here is the info I got. tor --version Tor version 0.4.6.8. Tor is running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, Libzstd 1.3.8 and Glibc 2.28 as libc. Tor compiled with GCC version 8.3.0 journalctl -u tor --since="14 hours ago" -- Logs begin at Tue 2021-12-14 04:28:56 CET, end at Tue 2021-12-14 10:19:59 CET. -- Dec 14 04:28:59 tor.piratenpartei-nrw.de systemd[1]: Starting Anonymizing overlay network for TCP (multi-instance-master)... Dec 14 04:28:59 tor.piratenpartei-nrw.de systemd[1]: Started Anonymizing overlay network for TCP (multi-instance-master). Dec 14 10:12:00 tor.piratenpartei-nrw.de systemd[1]: tor.service: Succeeded. Dec 14 10:12:00 tor.piratenpartei-nrw.de systemd[1]: Stopped Anonymizing overlay network for TCP (multi-instance-master). Dec 14 10:12:00 tor.piratenpartei-nrw.de systemd[1]: Stopping Anonymizing overlay network for TCP (multi-instance-master)... Dec 14 10:12:00 tor.piratenpartei-nrw.de systemd[1]: Starting Anonymizing overlay network for TCP (multi-instance-master)... Dec 14 10:12:00 tor.piratenpartei-nrw.de systemd[1]: Started Anonymizing overlay network for TCP (multi-instance-master). In the tor log I have: Dec 14 00:22:25.000 [notice] General overload -> DNS timeouts (162) fraction 1.0484% is above threshold of 1.0000% Dec 14 00:32:25.000 [notice] General overload -> DNS timeouts (154) fraction 1.0664% is above threshold of 1.0000% Dec 14 00:42:25.000 [notice] General overload -> DNS timeouts (140) fraction 1.0721% is above threshold of 1.0000% Dec 14 01:32:57.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Dec 14 01:32:58.000 [notice] Delaying directory fetches: We are hibernating or shutting down. Dec 14 01:33:27.000 [notice] Clean shutdown finished. Exiting. Dec 14 10:12:01.000 [notice] Tor 0.4.6.8 opening log file. Dec 14 10:12:01.103 [notice] We compiled with OpenSSL 1010104f: OpenSSL 1.1.1d 10 Sep 2019 and we are running with OpenSSL 1010104f: 1.1.1d. These two versions should be binary compatible. Dec 14 10:12:01.104 [notice] Tor 0.4.6.8 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, Libzstd 1.3.8 and Glibc 2.28 as libc. Dec 14 10:12:01.104 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning You can see the start was at 04:28:59 but it only started when I did "systemctl restart tor" at 10:12:01.103. I have this issue for some weeks, maybe since the late summer. I do not restart the Exit that often, so just 3 restarts due to some updates of Debian. Any idea how to troubleshoot this and what to look for? Thanks yl

5 7

[Looking for feedback] An easier way to declare families
by Nick Mathewson 14 Dec '21

14 Dec '21

Hello, relay operators! I'm hoping to get some feedback from relay operators, particularly those who use the MyFamily option, about the best way to deploy proposal 321. You can read the proposal at: https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/321-… The main idea of this proposal is to provide an easier way for relays to declare that they are in the same family. With proposal 321, each relay in the same family uses a cryptographic certificate to prove that it is in the same family as the others. (That's just a summary; see the full proposal at the link above for a write up of how it works, an a description of backwards compatibility issues.) Now, my question is, how can we make this approach as usable as possible? There are several different ways that we could have it work in practice: Option 1: Every family would have a shared secret. This would be a random file that you'd have to copy to every relay in the family when you set it up. The relays would use this shared secret to derive a shared private key. If this file is ever exposed (for example, if a relay is compromised), you'd need to make a new one, and copy it to every relay in the family. (Otherwise, an attacker could claim to be in your family.) We could provide a convenient function to make a new secure shared secret, something like: $ tor --new-family-secret <filename> Option 2: As above, except instead of the shared secret, it would be a shared ed25519 private key for the family. This would be an ed25519 private key that would have to be copied to every relay in the family. If this key is ever exposed (For example, if one relay in the family is compromised), you'll need to make a new one, and copy it to every relay in the family. (Otherwise, an attacker could claim to be in your family.) We'd provide a command to generate new keys; it would look something like: $ tor --new-family-key <keyfile> Option 3: Offline certificate generation with separate distribution. In this scheme, there would be an ed25519 private key for the family, but you wouldn't have to copy it to the relays. Instead, you'd have to generate certificates from the private key offline, and then copy those certificates to the relays. They would have a lifetime of N days; you'd need to make new certificates every N days. If a relay's certificate is exposed, you don't need to generate new certificates for the other relays. You just stop generating certificates for that one relay. If the offline private key were ever exposed, you'd have to generate a new one, and a new set of certificates. The interface would probably look something like: $ tor --new-family-key <keyfile> $ tor --make-family-certs --key <keyfile> --members \ <family_list_file> --out <certfile> --lifetime <n days> Then you'd do something like: $ for member in $(cat family_hostnames); do scp <certfile> member:/srv/tor/tor-family-cert done Option 3 requires regular updates to all the relays in the family, which makes it cumbersome. Its advantage is that if a relay is compromised, you don't need to re-key the family. Options 1 and 2 are less secure, since you have to re-key your whole family if the key is ever compromised. But they have the advantage that they don't take any maintenance in the regular case. Option 1 is a little more convenient than option 2, since you can use any old random file. But that makes it more error prone: if somebody chooses an insecure password as their random file, an attacker could guess it and become a family member. So... If all three of these options were available, which of these would you choose? Is there anything else that we could do to make this system simpler or easier to use? If I'm left to my own devices, I will probably just implement option 2 for now, but leave the door open for option 3 in the future. best wishes, -- Nick

5 11

bridge distribution mechanism
by potlatch 14 Dec '21

14 Dec '21

Hello Tor universe, One of the bridges I recently set up shows the Bridge distribution mechanism as https: Question: Is this an issue or does it impact the functionality of the bridge? Or maybe I made a boo boo during setup. Most of my bridges report Moat as the mechanism. Just trying to learn something. Best, potlatch Sent with [ProtonMail](https://protonmail.com/) Secure Email.

3 2