tor-relays

tor-relays@lists.torproject.org

31 participants
4812 discussions

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

Introduction from ellie (at) nicecock
by ellie＠nicecock.eu 14 Dec '21

14 Dec '21

Dear relay operators, I would like to take this opportunity to also introduce myself. Online, I most often go by the name Ellie. I have set up one relay so far, but plan to host one or two more in the coming days/weeks with more planned down the road. I am not even close to running the same number of nodes as some of you guys do, but I am just doing my part. All my nodes should be hosted under the tor.nicecock.eu domain. The domain originated as an acronym for a project I did with a couple of people. Unfortunately, it could not continue under that name. My eventual goal is to run somewhere around five to ten nodes. My current node is running on AS12876, which is quite a popular choice for nodes. I recognize this is not that good, but I figure running a node despite that is better than not running one at all. I am looking forward to talking and discussing with you in the future. Best regards in addition to a nice day, Ellie P.S. I hope I am not needlessly spamming the mailing list, I just wanted to introduce myself even as a small beginning operator.

2 1

Re: [tor-relays] Fw: is my tor bridge running ok ?
by Natus 12 Dec '21

12 Dec '21

hi Torix, The logs are indeed meaningful, I am confident my bridge is used : Dec 11 23:23:13.000 [notice] Heartbeat: In the last 6 hours, I have seen 5 unique clients. Dec 12 05:23:13.000 [notice] Heartbeat: In the last 6 hours, I have seen 3 unique clients. > There is a bridge tester page at: > https://bridges.torproject.org/scan/ This one only validate the ports are open. > As for finding out if anyone is using it or not, I use: > netstat -n |grep ESTA|wc -l This one does not limit to tor bridge On Sat Dec 11, 2021 at 7:32 PM CET, torix wrote: > > Dear Natus, > > So glad to hear you put up a bridge - > > > I'm writing you directly because I seem to have encrypted myself out of > being able to write to the list; they can't unencrypt what I write any > more to check if it's okay to put on the list. > > There is a bridge tester page at: > https://bridges.torproject.org/scan/ > To test your ipv4 orport, put in your ipv4 address of your bridge. > For the obfs4 port, be sure to put in the orport number from this line > in your torrc: > https://bridges.torproject.org/scan/ > ServerTransportListenAddr obfs4 0.0.0.0:<your port number> > Resulting page will tell you if the bridge is working or not. > > As for finding out if anyone is using it or not, I use: > netstat -n |grep ESTA|wc -l > to find the number of current connections. > Or, for more modern linuxes which stopped having netstat installed: > ss -t|grep ESTAB |wc -l > Or, if you are using FreeBSD: > sockstat -c |grep _tor| wc -l > > Going back to the log file: There is a heartbeat message that gives you > the number of users every 6 hours. Here's 2 examples from mine: > > Dec 11 14:16:03.000 [notice] Heartbeat: In the last 6 hours, I have seen > 20 unique clients. > > Dec 11 20:16:03.000 [notice] Heartbeat: In the last 6 hours, I have seen > 17 unique clients. > > > HTH, > > --Torix > > Sent with ProtonMail Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Saturday, December 11th, 2021 at 5:47 PM, Natus <natus(a)riseup.net> > wrote: > > > hi > > > > > just setup a tor bridge. how can I validate it is up and running ? > > > > > logs look fine: > > > > > > [notice] You can check the status of your bridge relay at https://bridges.torproject.org/status?id=<a key> > > > > > > > [notice] Unable to find IPv4 address for ORPort <port>. You might want to specify IPv6Only to it or set an explicit address or set Address. > > > > > > > [notice] your ORPort <ip>:<port> is reachable from the outside. Excellent. Publishing server descriptor. > > > > > When going on the link above I get : > > > > > > Bridge <a key> advertises: > > > > > > > - obfs4: functional > > > > > > > Last tested: 2021-12-11 17:38:47.790513642 +0000 UTC (3m11.984999137s ago) > > > > > Then any way to monitor how useful running this is ? > > > > > THanks > > > > > tor-relays mailing list > > > > > tor-relays(a)lists.torproject.org > > > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays