- tor-relays - lists.torproject.org

[Censorship in Russia] Make HTTPS/Moat captcha more complex?
by spaceoddity＠disroot.org 27 Dec '21

27 Dec '21

Hi there. I was thinking, what could be the ways Russian authorities could get bridges to block. One of the obvious ways to do this is to grab bridges from Moat/HTTPS, but since that would require solving a captcha, this would indicate its strength is insufficient, or they are able to crowdsource/mass solve somehow. The other thought is an attack via email. Can we do something with it, what do you think? -- Best regards, Space Oddity.

8 10

Moving relay to other VPS
by bobby stickel 27 Dec '21

27 Dec '21

4 4

Re: [tor-relays] Fw: Re: Bridge distribution method stuck at "none"
by - 24 Dec '21

24 Dec '21

Hello again. I'm found it weird that all resources says that "Distribution mechanism" should change after a few days and mine was still "none". So now I'm trying torix's suggestion and deleted the keys and all the /var/lib/tor/ directory, changed nickname and started it again. The hashed fingerprint for my bridge is now: 3B5D1AE581EE4113610E094D5993D6299E64EDEF Its the same torrc file I shared before, just new nickname. This is the log of the last heartbeats is the following, minus timestamps (I will update after one week): /var/log/tor# cat notices.log.1 notices.log | grep Heart | grep -v Accounting [notice] Heartbeat: Tor's uptime is 6:00 hours, with 0 circuits open. I've sent 1.89 MB and received 5.37 MB. I've received 38 connections on IPv4 and 38 on IPv6. I've made 26 connections with IPv4 and 0 with IPv6. [notice] Heartbeat: In the last 6 hours, I have seen 0 unique clients. [notice] Heartbeat: Tor's uptime is 12:00 hours, with 0 circuits open. I've sent 3.13 MB and received 9.85 MB. I've received 71 connections on IPv4 and 71 on IPv6. I've made 53 connections with IPv4 and 0 with IPv6. [notice] Heartbeat: In the last 6 hours, I have seen 0 unique clients. [notice] Heartbeat: Tor's uptime is 18:00 hours, with 10 circuits open. I've sent 5.93 MB and received 16.49 MB. I've received 141 connections on IPv4 and 140 on IPv6. I've made 85 connections with IPv4 and 0 with IPv6. [notice] Heartbeat: In the last 6 hours, I have seen 0 unique clients. [notice] Heartbeat: Tor's uptime is 1 day 0:00 hours, with 15 circuits open. I've sent 7.37 MB and received 21.77 MB. I've received 175 connections on IPv4 and 174 on IPv6. I've made 114 connections with IPv4 and 0 with IPv6. [notice] Heartbeat: In the last 6 hours, I have seen 0 unique clients. [notice] Heartbeat: Tor's uptime is 1 day 6:00 hours, with 14 circuits open. I've sent 8.46 MB and received 27.03 MB. I've received 194 connections on IPv4 and 193 on IPv6. I've made 136 connections with IPv4 and 0 with IPv6. [notice] Heartbeat: In the last 6 hours, I have seen 0 unique clients. [notice] Heartbeat: Tor's uptime is 1 day 12:00 hours, with 15 circuits open. I've sent 9.47 MB and received 31.66 MB. I've received 212 connections on IPv4 and 210 on IPv6. I've made 162 connections with IPv4 and 0 with IPv6. [notice] Heartbeat: In the last 6 hours, I have seen 1 unique clients. [notice] Heartbeat: Tor's uptime is 1 day 18:00 hours, with 15 circuits open. I've sent 10.64 MB and received 36.48 MB. I've received 229 connections on IPv4 and 227 on IPv6. I've made 181 connections with IPv4 and 0 with IPv6. [notice] Heartbeat: In the last 6 hours, I have seen 0 unique clients. I also added a IPv4 iptables rule just to count the traffic: # iptables -vnL|grep TOR 74451 14M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 6661:6662 /* TOR R */ # Is this ammount of connections/clients normal for the first day of a bridge? Thanks El mar, 21 dic 2021 a las 20:10, torix (<***>) escribió: > I'm writing you at gmail because I got a note from the list admin saying > they couldn't moderate my post because they couldn't decrypt it, so were > refusing it. However, you do seem to have seen my post, so I'm a bit > confused about posting to the list. > > Since you don't seem to be getting anyone connecting with your current > bridge and you are still stuck at "none", I'd think about just deleting the > keys directory: > /var/lib/tor/keys/ in linux > /var/db/tor/keys in freeBSD > This directory holds the actual identity of the tor relay, so if you > delete it and restart tor, it will make a new key and start as a completely > new relay, and give metrics a new chance to give you a bridge type. > The lifecycle of a new relay post which gives a month before it settles in > does not mean that you shouldn't be getting some connections in the first > few days. At least that has been my experience in the last few weeks > putting up a couple of bridges in response to the Tor Project's call. I > started getting 1-5 concurrent connections in the first day. I wish I'd > been paying more attention, but I certainly had a bridge type assigned in > the first or second day of running. > > Good Luck! > > --Torix > > Sent with ProtonMail <https://protonmail.com/> Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Tuesday, December 21st, 2021 at 4:03 PM, - <damisame(a)gmail.com> wrote: > > Hi. > Thanks for the suggestions. > I thought it will take a couple of days to show activity, not a couple of > months. > > This is my torrc: > ------------- > BridgeRelay 1 > BridgeDistribution any > PublishServerDescriptor 1 > Log notice file /dev/shm/tor-notices-bridge.log > RunAsDaemon 1 > RelayBandwidthRate 2000 KB > RelayBandwidthBurst 3000 KB > AccountingMax 5120 GB > AccountingStart month 1 00:00 > ORPort 6661 > ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy > ServerTransportListenAddr obfs4 0.0.0.0:6662 > ExtORPort auto > ContactInfo <address(a)email.com> > Nickname *(editted)* > ------------------ > > Ports 6661-2 are reachable externally. > > https://bridges.torproject.org/status says: > > * obfs4: functional > Last tested: 2021-12-21 04:39:48.514002439 +0000 UTC (11h19m41.110084213s ago) > > > Thanks > > El mar, 21 dic 2021 a las 16:57, <lists(a)for-privacy.net> escribió: > >> On Sunday, December 19, 2021 5:47:29 PM CET - wrote: >> >> > However I dont see practically any traffic besides when I'm using it, >> and >> > on "Relay Search" it shows as "Bridge distribution mechanism: None". >> > The bridge has been up and running for 10 days straigth. >> It can take many weeks or months before the first users start using the >> bridge. >> >> > At first I only had the line: "PublishServerDescriptor 1". >> This is default ... >> >> > After five days, I tried adding "BridgeRelay 1" >> ... if you set 'BridgeRelay 1' (this is absolutely necessary to be a >> bridge) >> >> > and "BridgeDistribution >> > moat", "https" and "any". >> AFAIK only none or any (default) can be set. BridgeDB then automatically >> assigns 'https, moat, Email or reseved' >> >> man torrc | grep Bridge >> BridgeDistribution string >> If set along with BridgeRelay, Tor will include a new line in its bridge >> descriptor which indicates to the BridgeDB service how it would like its >> bridge address to be given out. Set it to "none" if you want BridgeDB to >> avoid distributing your bridge address, or "any" to let BridgeDB decide. >> See https://bridges.torproject.org/info for a more up-to-date list of >> options. (Default: any) >> >> > Neither seems to have produced any change. >> > >> > Is this normal or could I have missed something on the configuration? >> Don't forget obfs4: >> >> ## obfs4 is used because it can do IPv4 and IPv6 connections >> simultaneously >> ## >> https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/README.md >> ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy >> >> ## The ServerTransportListenAddr line is dual stack friendly. >> ServerTransportListenAddr obfs4 [::]:443 >> >> > Thank you. >> If there are further problems, it is best to post your whole torrc: >> ~$ grep ^[^#] /etc/tor/torrc >> >> -- >> ╰_╯ Ciao Marco! >> >> Debian GNU/Linux >> >> It's free software and it gives you >> freedom!_______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > >

1 0

Bridge distribution method stuck at "none"
by - 21 Dec '21

21 Dec '21

Hello. I tried to set up a bridge on an Ubuntu server and it seems working fine. I can connect to it manually from different devices using the bridge address from obfs4_bridgeline.txt file. However I dont see practically any traffic besides when I'm using it, and on "Relay Search" it shows as "Bridge distribution mechanism: None". The bridge has been up and running for 10 days straigth. At first I only had the line: "PublishServerDescriptor 1". After five days, I tried adding "BridgeRelay 1" and "BridgeDistribution moat", "https" and "any". Neither seems to have produced any change. Is this normal or could I have missed something on the configuration? Thank you.

3 3

Tor Relay Operators Survey - Gamification Project - Miko
by Sukeshani Tayade 21 Dec '21

21 Dec '21

*Hello Tor Relay Operators!* My name is Miko and I am an intern via Outreachy.org. I am working on a project to understand Tor Relay Operators and incentivise your relay running experience. You can read more about this project here: https://gitlab.torproject.org/tpo/community/relays/-/issues/26 https://gitlab.torproject.org/tpo/community/relays/-/issues/27 We appreciate your contribution to the Tor Network and want to make your relay running experience better. We would like to hear from you directly. *Please answer the survey below* and be as detailed as you'd like. We're looking forward to your responses! They will be instrumental in directing our mission to serve you better. *SURVEY:* https://survey.torproject.org/index.php/459487

1 0

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 17 Dec '21

17 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

is my tor bridge running ok ?
by Natus 11 Dec '21

11 Dec '21

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

2 1

Mitigating log4j exploits
by Jens Kubieziel 11 Dec '21

11 Dec '21

Hiho, we got a notice that currently several exploit attempts for the log4j flaw going through Tor exit nodes und using LDAP. See https://www.greynoise.io/viz/query/?gnql=tags%3A%22Apache%20Log4j%20RCE%20A… The sender asked to do something against the currently running attacks. One possibility is, in my opinion, rejecting connection over ports 389 and 636. What do you think? Should we as exit node operators block connections over those LDAP ports for some amount of time? Best, qbi

2 1

Responding to Tor censorship in Russia
by gus 11 Dec '21

11 Dec '21

Dear relay operators, Today the torproject.org was officially blocked in Russia. You can read more about the situation here[1]. Russia is the country with the second largest number of Tor users, with more than 300,000 daily users or 15% of all Tor users. As it seems this situation could quickly escalate to a country-wide Tor block, it's urgent that we respond to this censorship! We need your help NOW to keep Russians connected to Tor! We are calling on everyone to spin up a Tor bridge. If you've ever considered running a bridge, now is an excellent time to get started, as your help is urgently needed. You can find the requirements and instructions for starting a bridge in the Help Censored Users, Run a Tor Bridge blog post: https://blog.torproject.org/run-a-bridge-campaign/ Gus [1] https://blog.torproject.org/tor-censorship-in-russia/ https://gitlab.torproject.org/tpo/community/support/-/issues/40050 -- The Tor Project Community Team Lead

8 14

I bumped out some more bad relays
by Roger Dingledine 10 Dec '21

10 Dec '21

Hi folks, I spent some time this week refining a new exit scanner, and today we pushed some new reject rules to kick out some relays that we confirmed were running mitmproxy to do more sslstrips. For past context, see these urls: https://blog.torproject.org/bad-exit-relays-may-june-2020 https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html https://lists.torproject.org/pipermail/tor-talk/2014-July/034219.html Expect some upcoming next steps that aim to change the fundamental arms race, including experiments to use https by default in Tor Browser, either via HTTPS Everywhere's "Encrypt All Sites Eligible" option (you can turn that on right now) or via Firefox's upcoming built-in version of the idea: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19850 For completeness, I'm including below the set of fingerprints that we bumped out. Note that we didn't confirm misbehavior from all of them -- some of them we're bumping out because they seemed sufficiently similar to the confirmed ones. If any of these are your relays, please speak up! Thanks, --Roger Group #1: COMID (coronamitmdisease2019) at OVH 019839E66C7229039367BEB4E83B27D08A9C2B37 110F26C0BFB2122BBB856EADC9A2D497989DE949 1B473D4B5C1D7C594E88B3044823D04E2BC51DBA 28EA24439668FBE905C801F8170C192E119C9FBD 378C5C8381700EC68EFDC427148CDE18DD94A014 48325E9146758F8636473D6D25FD4D7734E189CB 52DDF76A32CC3E0BFBAD72E511A0354343A224B3 7A8089D801EC09B20B1091CB031C79B7E0371818 7BD7DB37884F3DADC61E755FA9F03F499BC3C552 840C79C994150D6F6A48B5F8E8658AB74D36B052 852FB4885C5F9DEDE66BB9E5515A81EAE6E43B6B 8FAB1ADF9BE2D0E821AF92B8215F692CD715FD73 A2BA8791AA2A27DCB5B0C5B51E8CCF2337A5C1E2 BD32854443E891DBB685E43854BB382DEF081E94 C271F036CDFE8A90881B60712BF6ACF742259764 CA2F7497106CB8B9AAF0E1A7CF9866EAC9DB43B5 D26C58809FBC2C0D0251FB2991470A6AAB3EDC5B DE50C4066BE7200F5D6AD0FC88452667451D39A9 F2D5E3A3E8B11CA72FF340C450A46F4C67AD8D1E Group #2: info(a)cypherpunklabs.com at OVH 023455597DAB689EE84FB3A7BC7FC5F9A3E27FD6 044E647F34EDA4AC975EDAD628C4E9BCFFF1FB08 04699AF0CB2B5A7F5CF943D31011F50F601BE8C7 05601B110B888BF3A12E10E8BF3C0B02166BF3F1 075FDD85EF4B783BCC9040580168F1FC5576B101 09930800210FF35CE84F2DEEDB4F9B67812B9717 0B7B08C50E419004F77447A72FFD578061F58311 0BAE1E20ACCB1F454A3A473185D83743E140B9D5 0BB27C3A307B35B5B2D2E8774D69DF7FA4B97867 0BE6EEB76C5641BF5D2E63C49C28CD50D2A40C15 0BF30C2AC9DBEF9C79B1119808F2FCC3FD81EE0A 0D58067912EA84D955565C82A4C00A47CDEF11DC 0DD55CF27BBA1F51131A46BC0A0EED68A177D1BB 1766E98ECC8A457FDBCBA7322C93F51FE1F896E7 186FF078A2EE09E8208ACBF4DDB61FFF96AD64B0 1B1351D85E8328BE21539EA9C0C0317E3A1CE380 1BD9EEB6725555246E8ADFFA5FA6B1D82F43447D 1C11D59B0144E9B33BB932A031BA8A3A5B81C65E 1D0971FA9B98AE2807D6A44AE6EB7EB120AB5675 1D515E91312D5F79895D607D6C27392DD5F6A84E 1EC0CCAFA8ABD5470B062AF470EAC97DD069C655 1F00A270AFDA1172DEDEC138AFEE977CFFB0FAD1 1FD39D081A3AA8E3D6F0962F8281A448D536C879 2369F6855A7CF31E3174CE26678FBBAD6A31D883 23BCFD8AB533AAE05639D1D79A445DEE76F8E57A 2541C0EB6F66C1344B3F14AB65EE7D6882EEF15F 29EC42BC7A3E7ED811578D5F656EC76D7A7AA2A5 2DE12251A7AF25B2CDFA9DE0F1B4022685ABAF3B 325499E7D6927D51229019F2EE031F26EBE095BB 386425D28458D4DB41F74F256AFF99ADB7E25271 38C36322890194015837A1085907DFA6AE3A9B00 3A6164437EF523E4907E7D97CAB135EFC39621F6 3BB398CA2D1F1E83AFC46641ABF8FECC989B8F19 3C5491293747761AFE9AF014FDA4B92960304D21 3CAA25A190B2F030DE86D0E99329E4D399472FB4 3CE91268F607E373482D1BCD33018CF1C77FAFA6 3DF6717E1C62D9ACF65CD5B3C609FBB271D9586D 3EE2A784ADB2F56E631F281F2688104A656E19C2 41280DE9ABE5BF10F7F5DCB13A28C07082064147 41E9201B42807012BCAFA6B94BCF9AD00CD787EA 442058BAE48FDFA68A3992988CBA6E2035FA8782 446FA7DE8A5DC2F2B0EBB9083753D127BB217F60 466F6F3B37435A6285C1F73F49EC58FA9D3A5260 47B22D6B46447B533E962966B9559E249B6F915C 4B777C07DFB28938D7D9B84737275F2412B5CA2A 4C52890A00964648E3AED7EB7CB178BA082610E6 4C6E75E65818844B7D3F3A8A9666525680006EAF 50A4A3A09AC7BC09F578670618A9BB864772EE03 554E9EE1586220B016B7C43490E7398F57C254D5 5A8A80399011B703FDB40E11226A389162DE0DD1 5BA611940BC239597312636D257F615F4F4D7BEB 5E6CB5FC020088CFC99342784A4109E468D7C94A 60D6F3FEE07527E749BD6BB3E401E5EB389EA45C 62CC081F58E5415DDD49A20D80A0E9A8A2E35CF3 63E4BD985E436877C471A743F1625F10FA114458 678FDB3BA0EEAA2572329A0BB0FF50E449D714ED 67FBB854B6DBD2DCBA5747FD761BF36096EFC0C0 6B6B3650F2FF83BD767AD84838600C62F937558B 6DA708660BA6F0BE1B67434951F0D0FE6AE72728 753C8EEDB1C2A9E1DBBF4DF75A2F549FD1A7F0FC 8002F46087D145E1CC5F4F11725494059E7A823D 80DF1465F2F27AA933DDB3A8F8A2AE06D3D859DA 823C31DD41F31ECDB44DB17198EAC2EDB7A295E8 85BFDBFCF9E711CF0F1A22C115368724D7C101F7 85D895B55F1A021663D441587F4FD822082E73C9 8668B39793EBDADD148AE8BB256B1E2E6ACD78D5 87B449E227ACB5C3FEB580942242183993866138 8D112569E620CB316F1FDC08BCFD93FF54F22ED9 8D599159A555665F199DD0F9E81277417C8D3973 94729C093EBFFC6102C47EE1EB40A8827AEF28E8 968CF9A51740B682ABE4DB11829488281B66DBD8 99F01989477E1F553BE789E25FB63CC2A2276E33 9A46602C82BD2C174F1C115A1D6E012DD0DFB57F 9C2EF7092D80859AC3DD4A39DF50B725D2BC3D5D 9CA1FCF374E5CE8F652DB08B16BB874EA839C0BF A3317BF385CFF595CC27997BB5A6C2FB35846D47 A6DBE4FFB33677E56BBBD0911AA489927650ADCA A7FA78D175541179556D66C8C78D69D238274F7A A81B621D6401BBEEC8E2C84228141BAFA711D0D9 A8D70BB95B76B3B5E6F6B4E30C2EFB11A21E9D1F A8E6126DA7D6DE9A719162CE8980F8755B612F21 AED640FB85D0A5C43C756FBEE19D1075DAF8E686 B34E09B1C68F46483A1A90551ACC78D87C80C08A B6F6B44DF12B2F1B74B666AA48F2BA0E5CFDF169 BA38FDB6FE97442388C35FE83F371BB1C6C4324B BA405E953DBE33BA2388F6B5954EDFBCE4CD1196 BC70877D0CBDFA77E6B4B88DDC23D03F8299CC02 BD9E37F7FD8773AD0C07B22394F179288DC5E2CC BEE5A27A9DD05BD7D9B6E046AEDEF43D2A4B85CE C31A5F636926B69C72F992F005D0BDF48040B283 C50ED548D22C1908E58AA194AD3DC966FD267E06 C6F1E2ECA92A5DE6710F1317DB040EF2CFFC5C92 CDAA1A9F705EBE23E9FB63B3EFE6699205E2F8C6 D018720BE031BA9CC0DF4C0E21ADBC649C325C62 D2816DE9B3040231DE6A431583C26FE65B5C929D D57751F73AE9DBFEAFAC282473615E5F6D269614 D7204D395ED3E4B6F6D81C38D8D6A9241F58250F D74C47EA991FAE041C2CBB233493C6780B197A14 D888307FB9A44E75FEDF0DD2DE3AB9659E6DC6F9 DC74048330C6037ADC505E0AF63E2A9F765F6B57 DCB6273B2D2AD09AAC021141136CD461994D1533 DFE448D8C5D81AE687289A225B64F704A7FAC877 E5A3F4D29B0E3AC5DD93D9921FE203702F558BD0 E781B862FEBE3C40029A0350BB0ABF4E184086DA E8F32BBFEAD7EDC6A40732EAEB15CF5C6DEFF225 F0CD6DD3766EFB6CB409EB148B6B22FF0B765533 F6CDD5AAF675F44B88BB326EC0738BD7277CBC12 F8E6613A7AA382960E00FC70A2E15A7B2F3F3FA0 F9DF89DCD30D238443245B5483A5E10F3D52C101 FA611C0BABB9DF7A63AC2877A5AB5A6880FBA51F FC33CA0B739EB8290180C7D22A536726B8EE90E4 FD00BDB335960AFDCA6CD565B81DEF2BA7F27E7D FE9313D50FB0E68F674812BF7CED0D8F2C2B65E6 FFF5DF7E9EF2A78210BE8E17E396CFC79797AC92 Group #3: Cypherpunklabs(a)protonmail.com at OVH 0D97E4B39B1986B688E90BE1FD996E492F2552DB 0E0D2A2E71A61B9D209DB4CE5E6DBEB98473E4EB 175D1B74B0271F5997C27E020AA167A013FFB7C9 215A723CB44D8ACB001D12C7832FC742921B4F64 241F67E50CA7D5E522F94E28B5AB5ABE4F166616 2723A5FFD3B6ED842EB44C380D3AB4D26DEF60AA 34BA457C5120D5E7DA9513C7B98733C57503E3E6 3A992EE90A372FF4ED0DB1E26D9662E967C84A92 3DAEC5687EAB19CC9FBE98303780137E143236AB 4169E219D6FFCF419A5F5DA6A66E0DC5782F8F8B 42215683AE0D359B6BADF2674D09BEA348BE388A 438587D73152254E935FC1D387003DFA18166EC5 56B310D18861A5F2A57D73269B6C11EDFA4EED1A 63584BC1EF29E794A63C264136D7825C33F0889D 78E40CFC92AA9265BB50494B75BE8E7F94659E8E 8049F8C058587A66246E8A93A56957CE29165F72 84D4A8CCE76EEAC3FC45ED7A78A05F7DCD68CE72 A613E402885F5D248889CD6EA85DE61D022D760E B3AA9132A7D759863BFAB6CD12DA6646F2A5D1AD B4598727C0B2A1313AB9DE822EDC6ECFDCC78FC0 BE1E17C00A4BE0FF280CFE062D03F261061E2E63 BE48173BCF9F2C3448192916BEEF01EA745F7DA3 C1C568D3802481F1BC15F9CB75A4B4DF7592BE50 DC818C243B318D19D07DACFC2E7CAD327C7E0B3E DE81E82F60AFCA34FB5F94D78F590FEEBB435CDC E05546C3458B68C2B1ADC7273AE0539E6325B910 EBF91C6220CE4890E2E94D32F3B6B96991ADC807 EC1EEF4ABBAA11CE8C978E6C87182F63AD27A4F8 F5AD7DE58D0E038B48761AD995F9117DA072BA47 FABCC633B0DEEE6FABEF3FA415A2B0038B2A5A00 FC8C3644FEE491C828EF7A980F9E2CB0D12F4D0C Group #4: other OVH relays probably run by the above 029F57C3B3504B797C189C208AC57B5D141F66D3 05EEF2F6029F70734AC5F64557AA2FE37306214F 11F30B96054A494093AE43310B1BD681AF76CADD 13E07E74D492BAC41B6C83DF66CD6022C576C4CF 18D0C3D3145B3F6FE48D13030A3B62641CBD3969 199937E2431394D8FE1219535763ED45DEEC6F9B 1B7A8EB93B36BAE221B5E0B66688864F508CDEBA 2254F9FB12C036595777E3C55C7F9AEEFDB3A0A9 309A43E7861F9DDCBF9C063B7FF94C53C7784BCD 336815FFC4B20050F240827FCDD20A66454C538C 3EAD45A64281E3447EE501B3D88CA8FBB041C749 4ADCECEF8450D38FAD26154A3689CF5DD53121EA 551CF8E26FD81CD95EC75E7530A6ED5120AFA769 56731D73A7BF7600C2942ED84F2371B9BE26117C 6513031975D1B4835C5483F482152B85BBA8F2DC 7F52A31991B48A95A52EDE2CA4E161ED70124B4A 815E359B9C9CC44B9CE2D7233D40E96AF9000206 89BDEBC7DC4FB7FAA0914E18167F3E9A69E20700 8D4AA79E47B1C99116DC8E8F301BD574021B88AE 9CBF4C88F2C687DB501A374ABB960EDBAA1CD911 A249B7EE9F843694A8CCE1DF8DBE8627A1EA51CB B2DB1519E42B22BF2C204D2873A2021BEBD7249E C52426AA31F0D90A4E53320858B98547A81BC86D EFAB57D3EBABB4F922F850763E88B447A2F4CC09 Group #5: at Frantech 13BFB7E95E303AC22A005F7D4D08CA9655925B40 14F21BEDEE20BED716234E7026822DF9E69EC356 1EBE3083FCDC9658188A2C7F67B83C531E641039 1FBEAFC6CFE71F1EEC3D5F62A2D896B1F87B2F4D 258837F888FF885131F8F12BC409D69F99597E6A 2DBA4CFFFD04A3EDA74A58264B4E4F351AA0F5A2 3D07B333ED3A81C557D39DE8A4EABD9BC0D6B0C1 3DCFC8F04E088BB33228FED97662D4E87B0F195A 3DE14798CDD62F6FA29DF21F418B4DFCEB0D59F4 3EAA79A75F96F4A082DB92E5FA231452BAD3F80C 4084E7226F6A6463C32F28841EA10A7796D10254 475C893CCA9661B407865B6DBB30C021AE45F1DA 6636D34B1502FABFE0DF848043CBCC0E4C52F12E 6E4DC86BC268306583E6C5640F11F17677663EDE 70797E7080F116E302A0F2A8F901FE914A3E625F 817C637920A7D4036CF665C6EC2D9842A7E73B77 85C8DBFB5574A338CAC8603CAF330EBF93219079 8A4C65C62D82C8783A6B51379A0E033464A4DF3C A40D5345ACA7439DAEA3801C3C473731B68A6E9B A95E579F730F719941392B6282676319839627F5 AD2A2BCC14044DA38F17FF37E6416C30BA1DF80B BCE0092B89D2C804483161D6E4C8FC81C56AA2B6 CED3133934C7B50F5A66323BC37AAEDDC875460D DB739627A2E20DE302A0D25F21B8B372D4AC2963 F44CDC27499333A14D55B8E28B9240BC8B206532 Group #6: at Leaseweb 0110D7D65C572B36C4CF4DD564B0BBB0B2ABF98D 08D8EC605A5CF77B6AC3F9CF34FA2B32E6F0EB3A 0B477F70980938C5287C04A8256951DEDBB72E4B 17038EAF590FCFCD4D17BF800892D61498D922D2 1818B3DA74DCBFC796CBA1011CEF41329B500DA6 1A7C2D579CDCE10C85E42FE515EFBA48A17A7D17 1AC81B2F05A3EE1DFEA330D3FD981E2E7F450C79 28724DB378396B1CD079D75824D9ADAEABC4C469 289730865CD9615FDAE620C65C973B3D99F6BB07 29AA1984FEEFA60093F72160B5EF44CA50B4EBBD 319A356599E538FC22697F8E982D94E0611C800B 333396E790E6CFA31C594B0D5F08DECBD02F8FEA 349379251F9F22044F46B214EC793DF724341096 36A358DC10EC2195303E141FC408A0706E5DFD81 3767BCA088F4C54D688F47C57B9868C9DF7D8D64 42EECE234646FB6CA84552BE7C915867E2ACDAC1 46A97AF8E2E20178EDD4D9F931B054FC1BEDC00A 47E7F131379F8DEC0909F2F9395331F4C67A538A 4839BD15B8E8BBDA5CDF304ECD7516D104CDC7F4 48E6494B14CAA7DFB4D87E0A76CA829F37C8D1C3 590D532DF6DB0E4E55150E397F2EFC3ABF76E755 591361152F37D13DCE8FA5827D109071725416FC 59571FEE54462C0E1B540D1E155B2334B9F10498 609A3FC47277EFD1683A0FC5A5FD07E261D0833B 612BF4A52D0DE957BBE376D4ED5A4203F9B2D7B6 62074297A05126F4C9C4F30F1338FD6C69099623 6A676D859C2D12CA8B699E710DF63CACC406B08F 6C03F70B7A90BF179ABBD3E0A854C2A1AF123966 74F71248F22646392AF63D4C4170C3B3A02E48A7 777F3A4B86A4042489F21F0CE608BDB8026BFF5A 77B6C374D5E16FDFC7698A645383CA9914F379ED 7BA2E40A27A96505FD22CB3BCD12E3B189CFFCF5 7E8834745EF551B668F83489F56D24B05A1F897F 808B7A04D08C6D2DE38FBE3D25EC7BC745B8D341 85F1A5CBFDE60BC53F00D1E98165A259AB984B58 89CB9B4F63638DB8C3702E0990845B2170B914BA 8AB40AD126DAC0C5A7C04B17CD85315E0D32B14E 9C432CC79130F4B923ADCD853A1ED621798728E6 A1F0D5720A71E6608DBB488CEA25BD5F1FA6E95B A41E8E3246F5750A16566DF04B38CE82CB111879 A47CF942FED91883C7EF8A8431939010CE95B206 A60A7FED7F5BA22E4B37CF238957BEF152474DA5 A64ECD9EE939825EF430175365E83643FE190BD1 A95F8F3E558D0D5B4CD3BD935EEEA14C73094A52 AE073E38C4DFF57D1AB187AF8FD523F76A9F5CBD B38F79C0789282F69D787B2133C9F8F4D1FE95E6 B3BC12E565A58902BD4E73EAFFC6AA98C46F417B B5F6D1B3AF78C55369262DD17D11420C6862142C BA100669E3D81203339579FE2224D0A7E37422AA BD7D0FB739E204D23B1B0B74DC9D8E311A0552A3 BE220BDCF8AE4E9F7DDAD2BAF85C2B4CB1A592E1 C14DE0D48928ABE0C15837CF35D070E0A3B8F0F4 C5197F6405A6F1423978683272A648FF79833F7F C556E08E13E012ED234362C1EEBC0588AAF1F1FE C75B26E3D4675F93F15AA2518860302A43D9BAC3 C85B7E5F3D06AB55AB0465E5CF66E777B1375DE5 CCC48AC17A89195AB8552EE9B5734C40B47B1075 CCF5C7C279A21C592E5DDF67D57542DD84C7146A CE67975EF0235DB732ADA85C6BF36CFDEFA18555 D25B78BB13249FA73B1AA5641847A66BDF014A6B D35EF561445474543064CC0C531BE0F3CCD198A4 E158EAA8788B8CFFF06A4D888D0C6B28DC1F057B E4B00CD81069AF2C0841B82A582C63AA32F03B0C EA8762F2D07FD5FA29B6BE05AA567A28D1545B4F EF0682CFD3724312FD550EB9646F72EFCFBA1B1D F788B67C42309E3B3A889E4CADB75D962CBF81C5 FB71593F68213499DA493FF6A4BFE015203272C9 Group #7: other 4E6C7297F16523A236EE1A2EE23AF54ABEF15490 55D490E9E440DD4458F16ABCDD79F48396D55EA9 78F699D58F3353AB6C4CE39E3BD96CE87439753A B1896E58FDEB5627B6B8334E6ABD42767AB8B0D9

5 13

Re: [tor-relays] tor-relays Digest, Vol 131, Issue 4
by imran qureshi 08 Dec '21

08 Dec '21

hi i don't understand how to run relay on my laptop while i run orbot on my android On Wed, 8 Dec 2021, 17:32 , <tor-relays-request(a)lists.torproject.org> wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Responding to Tor censorship in Russia (gus) > 2. Re: Responding to Tor censorship in Russia (John Ricketts) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 7 Dec 2021 17:16:05 -0300 > From: gus <gus(a)torproject.org> > To: tor-relays(a)lists.torproject.org > Subject: [tor-relays] Responding to Tor censorship in Russia > Message-ID: <20211207201605.GN2321@localhost> > Content-Type: text/plain; charset="utf-8" > > Dear relay operators, > > Today the torproject.org was officially blocked in Russia. You can read > more about the situation here[1]. > > Russia is the country with the second largest number of Tor users, with > more than 300,000 daily users or 15% of all Tor users. > > As it seems this situation could quickly escalate to a country-wide Tor > block, it's urgent that we respond to this censorship! > > We need your help NOW to keep Russians connected to Tor! > > We are calling on everyone to spin up a Tor bridge. > > If you've ever considered running a bridge, now is an excellent time to > get started, as your help is urgently needed. You can find the > requirements and instructions for starting a bridge in the Help Censored > Users, Run a Tor Bridge blog post: > https://blog.torproject.org/run-a-bridge-campaign/ > > Gus > > [1] > https://blog.torproject.org/tor-censorship-in-russia/ > https://gitlab.torproject.org/tpo/community/support/-/issues/40050 > -- > The Tor Project > Community Team Lead >

1 0

Is Tor Actually "Blocked" In Russia, or Are Some Users Unblocked for now?
by Neel Chauhan 06 Dec '21

06 Dec '21

Hi tor-relays@, While I don't live in Russia, nor are my parents from Russia (they're from India), today, I noticed these articles that some people noticed Tor is blocked in Russia (sorry for being late): https://ntc.party/t/ooni-reports-of-tor-blocking-in-certain-isps-since-2021… https://forum.torproject.net/t/tor-blocked-in-russia-how-to-circumvent-cens… Yet, when I look at Tor Relay Status, I noticed many relays hosted on Russian residential ISPs are still online, and only a few aren't: Moscow City Telephone: *https://metrics.torproject.org/rs.html#search/as:AS25513 Rostelecom: * https://metrics.torproject.org/rs.html#search/as:AS12389 * https://metrics.torproject.org/rs.html#search/as:AS42610 * https://metrics.torproject.org/rs.html#search/as:AS34168 Vimpelcom: * https://metrics.torproject.org/rs.html#search/as:AS8371 * https://metrics.torproject.org/rs.html#search/as:AS8402 MTS: * https://metrics.torproject.org/rs.html#search/as:AS60496 I didn't notice a big reduction in "relay" users on Metrics: https://metrics.torproject.org/userstats-relay-country.html?start=2021-09-0… But did see an increase in "bridge" users: https://metrics.torproject.org/userstats-bridge-country.html?start=2021-09-… And most Ooni results still show Tor can connect fine: https://explorer.ooni.org/search?until=2021-12-06&since=2021-11-29&probe_cc… I feel it could be possible it's one of the two: * Most likely, the censorship rollout is in stages. Some users are blocked but other's aren't, where it wasn't rolled out is still unblocked. * Less likely, but Russia found people could use pluggable transports, like HTTPS obfs4 bridges and maybe they found blocking Tor itself is ineffective, or trying to block "meek" users ended up blocking Microsoft and ASP.NET/Azure-based webapps. Disclaimer: I work at Microsoft, but not on Azure as of now. I did however interview for a position in the Azure umbrella (not on the CDN however). -Neel Chauhan

2 1

Re: [tor-relays] tor-relays Digest, Vol 131, Issue 2
by Ali Druno 06 Dec '21

06 Dec '21

Hi! I've also noticed suddenly 3-5x more bridge users using the one I run with a concrete difference in Russian connections highly increased in number of unique users compared as the others countries which are looking stable. (Sorry for my bad English, I hope it was comprehensible enough) Have a nice week! Nils Le lun. 6 déc. 2021 à 13:00, <tor-relays-request(a)lists.torproject.org> a écrit : > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Snowflake's package for FreeBSD available (Vin?cius Zavam) > 2. Is Tor Actually "Blocked" In Russia, or Are Some Users > Unblocked for now? (Neel Chauhan) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 5 Dec 2021 19:30:38 +0000 > From: Vin?cius Zavam <egypcio(a)googlemail.com> > To: undisclosed-recipients:; > Subject: [tor-relays] Snowflake's package for FreeBSD available > Message-ID: > < > CA+Kr6DNtCC6-iQ7Et71UyTkqArcB_ruO4CcY8nMUm278BJaeyg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > ol?! :) > agora temos um pacote para instalar Snowflake em FreeBSD. aproveitem! > > tl;dr; we now have a package to install Snowflake on FreeBSD. enjoy! > > since the 14th of Nov 2021 we have a port that builds a Snowflake package > that can be installed on FreeBSD. it gives us all 3 different > features/functions that we can use Snowflake for: > > - client > - proxy > - server > > don't know Snowflake yet? > > - https://snowflake.torproject.org/ > - https://community.torproject.org/relay/setup/snowflake/ > - > > https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… > > if you are using the "latest" branch of pkg, try it out! the package is > called "snowflake-tor" > > # pkg update -f > # pkg install -U snowflake-tor > > wanna checkout the source of its port? > > - > > https://cgit.freebsd.org/ports/commit/?id=057c0c3c0645c0b237bb2a96dda440e04… > > did you know about the "Run a Bridge" campaign? > > - https://blog.torproject.org/run-a-bridge-campaign/ > > that's it! stay safe and have a great one > obrigado ]=) > > > -- > Vin?cius Zavam > keybase.io/egypcio >

1 0

Snowflake's package for FreeBSD available
by Vinícius Zavam 05 Dec '21

05 Dec '21

olá! :) agora temos um pacote para instalar Snowflake em FreeBSD. aproveitem! tl;dr; we now have a package to install Snowflake on FreeBSD. enjoy! since the 14th of Nov 2021 we have a port that builds a Snowflake package that can be installed on FreeBSD. it gives us all 3 different features/functions that we can use Snowflake for: - client - proxy - server don't know Snowflake yet? - https://snowflake.torproject.org/ - https://community.torproject.org/relay/setup/snowflake/ - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… if you are using the "latest" branch of pkg, try it out! the package is called "snowflake-tor" # pkg update -f # pkg install -U snowflake-tor wanna checkout the source of its port? - https://cgit.freebsd.org/ports/commit/?id=057c0c3c0645c0b237bb2a96dda440e04… did you know about the "Run a Bridge" campaign? - https://blog.torproject.org/run-a-bridge-campaign/ that's it! stay safe and have a great one obrigado ]=) -- Vinícius Zavam keybase.io/egypcio

1 0

Recent rejection of relays
by Georg Koppen 02 Dec '21

02 Dec '21

Hello everyone! Some of you might have noticed that there is a visible drop of relays on our consensus-health website.[1] The reason for that is that we kicked roughly 600 non-exit relays out of the network yesterday. In fact, only a small fraction of them had the guard flag, so the vast majority were middle-only relays. We don't have any evidence that these relays were doing any attack, but there are attacks possible which relays could perform from the middle position. Therefore, we decided we'd remove those relays for our users' safety sake. While we were already tracking some of the relays for a while, a big chunk of them was also independently reported by a cypherpunk and nusenu helped analyzing the data. Thanks to both of them from our side. Foe what it is worth: a large part of those relays did not set any valid contact info and/or when we tried to contact some of the relays' operators the emails bounced. However, we sometimes need to have ways to reach relay operators, be it for debugging purposes or for helping them with relay misconfiguration. Thus, please set a valid contact info when running relays. Finally, anyone running relays: try to get connected to the community so we can build some trust among each other. That seems to be an essential part in our long-term strategy to fight bad relays trying to enter our network. Georg [1] https://consensus-health.torproject.org/graphs

10 16

Relays running an unsupported (EOL) Tor version
by Georg Koppen 01 Dec '21

01 Dec '21

Hello! Relays running unsupported Tor versions is a problem we have never really dealt with in a systematic way in the way. Some of you might recall that we (with the help of volunteers) tried back in 2019/2020 to get operators, running an unsupported Tor version, to upgrade[1] but then we dropped the ball. Alas. We just started that process again by contacting every relay operator running an outdated Tor version (any version not 0.3.5.x or 0.4.5.x or 0.4.6.x or 0.4.7.x) by email where possible. Additionally, we created a wiki page outlining the current process and things we still need to figure out.[2] On that page we plan to make statistics related to the EOL relay removal available as well, including the final list of relays we'll reject. Thus, stay tuned. Feedback, as always, is very much welcome! We plan to keep this topic on our radar this time while refining the process as we go. Meanwhile, if you are running a relay with an unsupported Tor version, please upgrade for the sake of our users' safety. If you need help, join us on #tor-relays or #tor-relays:matrix.org if you use Element. Thanks, Georg [1] https://blog.torproject.org/removing-end-life-relays-network [2] https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Relay-EOL-pol…

2 4

Rerouting exit relays detected - EXNODE35037
by nusenu 24 Nov '21

24 Nov '21

BadExit: Rerouting exit relays detected (1) The following exit relays are routing their traffic back into the tor network: nickname: EXNODE35037 First seen: 2021-11-22 15:00:00 Consensus weight: 1 AS: ITL LLC OR IP address: 195.123.220.84 Exit addresses: 185.220.101.138 195.123.220.84 https://atlas.torproject.org/#details/E6FBCC437A708ADC396FDE12ACF7E333BEC02… -- https://nusenu.github.io

2 1

Mystery with Exitnode 4273E6D162ED2717A1CF4207A254004CD3F5307B (176.10.99.200)
by Tschador 23 Nov '21

23 Nov '21

Hi, in the last few days I noticed a curiosity with the Exitnode 4273E6D162ED2717A1CF4207A254004CD3F5307B: Every time I call 'https://www.startpage.com', the URL in the Browser changes to 'http://localhost/'. Other browser: same effect. Other sites - no problem. Other Exitnodes - no problem with 'https://www.startpage.com' and other sites. What's going on there …? Regards

2 2

Massive CPU load on high capacity guard node
by failing.flyaway443＠mailer.me 20 Nov '21

20 Nov '21

Hello Everybody, my relay is now almost two weeks old and has the following flags: Fast, Guard, Running, Stable, V2Dir, Valid. I lost the HSDir flag because I had to restart the Tor process, my downtime was just a few seconds, maybe that's why I kept the Guard flag. I was expecting a drop in traffic when I got the Guard flag (as mentioned in the FAQ), but the opposite happened. At the moment there are around 15000 active connections, over 11000 inbound and just 4000 outbound. I looked at the connections in Nyx, and it seems that my relay is indeed used as a Guard node (most of the IPs are "scrubbed" and the outgoing connections are to middle nodes). Before I got the Guard flag, I had around 5000 connections at the same time and was relaying traffic at peaks of 55MB/s. My server is connected to a Gigabit link. It's not a regular VPS, I have a dedicated CPU with two cores and dedicated 8GB RAM. Traffic is unlimited. The problem is that I'm now relaying traffic at ~25MB/s, and whenever there are spikes of over 30MB/s the CPU load on both cores (!) is very high. I'm still moving ~5TB per day, that's a lot, I know. But there would be even more possible with the internet connection of my server. My Server has two dedicated CPU cores of an AMD EPYC 7702, but unfortunately I only get the base frequency of 2GHz inside the VM, not the boost frequency of 3,35GHz (misleading information on the hoster's website). I could relay way more traffic if there wouldn't be this issue with the CPU load. This is the bottleneck, the 1Gbit link is guaranteed. I read in the FAQ that a modern CPU with hardware acceleration is able to relay traffic @~500Mbit in both directions. The EPYC 7702 supports AES-NI. I checked this, it is activated in my VM. I'm running Debian 11 Bullseye and tweaked the networking capabilities with some instructions I found from torservers.net (mnostly sysctl.conf tweaks) There is no additional software installed that uses lots of ressources, just a few tools. Here is a screenshot of Glances during a traffic peak (I set the Tor process to +10 on purpose): https://i.ibb.co/8brmZkf/glances.png The average CPU load is ~1.50, this is still ok for a dual core, but it should stay below 2.0 (at least it should not go above 2.0 for more than a few minutes). Does anyone here have an idea what I could do? Since the load on both cores is pretty high, I don't think it makes much sense to set up a second relay on the same server. Of course I could throttle the traffic, but is there anything else I can do? I rented this rather expensive server to help the Tor network with a really fast Guard node... Thank you everyone for your time and responses! Have a great weekend! Best Regards, Elias

3 3

relayor v21.2.0-rc is released: prometheus exporter support
by nusenu 19 Nov '21

19 Nov '21

Hi, relayor v21.2.0-rc is released. relayor is an ansible role that helps you with running tor relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor-relay-ope… NOTE: This release contains a backwards incompatible change, if you upgrade from an older release please read the upgrade guide before upgrading. https://github.com/nusenu/ansible-relayor/wiki/Upgrade-Guide-from-version-2… This version of relayor uses MetricsPort (when enabled) via TCP on 127.0.0.1. This is less safe then using unix sockets because all processes on the system get access to tor's prometheus metrics since there is no authentication supported. When MetricsPort gets unix socket support, relayor will switch to that safer option. https://gitlab.torproject.org/tpo/core/tor/-/issues/40192 Changes since relayor v21.1.0: * major new features: * add support for tor's prometheus exporter (MetricsPort) * this is a relayor beta feature requiring tor >=0.4.7.2-alpha) #217 * generates prometheus scrape, nginx reverse and htpasswd config files on the control node for easy copy paste into your prometheus/nginx configuration * every tor instance gets an id label (IPv4_ORPort) * support arbitrary torrc options #192 * fix broken debian tag - reported by @jn9999 #224 * fix broken link - PR by @jn9999 #223 * README: * make clear that we do not remove previously managed tor instances on config change - reported by @tsekityam * update OfflineMasterKeys link * make apt update_cache configurable * drop support for Debian 9 * increase min. ansible version 2.9.23 -> 2.9.27 kind regards, nusenu -- https://nusenu.github.io

1 0

Help Censored Users, Run a Tor Bridge
by gus 18 Nov '21

18 Nov '21

Hi everyone, We're launching a campaign to get more obfs4 bridges and help censored Tor users. The campaign will run from November 17 to January 7, 2022. You can read all the details below, including our special reward kits for participants: https://blog.torproject.org/run-a-bridge-campaign/ Join us and help censored users! Gus -- The Tor Project Community Team Lead

1 0

Loss of Stable flag
by Arlen Yaroslav 16 Nov '21

16 Nov '21

Hello to all relay operators! My relay Deepsky (09A70E396DE93F54D4541BBB0EC8E2B23761F34F) has not been receiving the 'Stable' flag from the DA consensus. Up until recently (the past month or so) it had been assigned the full complement of flags. Nothing has been changed on the server and I am not aware of any issues. Would any of the directory authority operators be able to shed light on why some of the DAs are not assigning it the flag? Thanks!

3 3

Compression bomb from dizum
by Logforme 15 Nov '21

15 Nov '21

Got the following in my log today: Nov 06 18:19:01.000 [warn] Possible compression bomb; abandoning stream. Nov 06 18:19:01.000 [warn] Unable to decompress HTTP body (tried Zstandard compressed, on Directory connection (client reading) with 45.66.33.45:80). 45.66.33.45 is tor.dizum.com, a Tor directory authority. False positive or a problem generating directory info at dizum?

3 2

Questions about my tor node
by Bobby 15 Nov '21

15 Nov '21

Hello I'm running a tor node and I paid for a VPS for the express purposes of running that node. I have configured it to use almost all of the bandwidth of the VPS and then to allow bursts to use all of the bandwidth I have also set it to serve directory requests. The server also has 1GB of ram and 1 CPU core. Is this good enough to be helpful in the tor network?

4 3

Re: [tor-relays] Hardware requirements for a fast Tor relay
by failing.flyaway443＠mailer.me 13 Nov '21

13 Nov '21

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >Since this is virtualization, make sure that features such as AES >acceleration are active. Yes, I have tested that. Is active. >The number of cores is not really relevant since Tor is not >multi-threaded. The EPYC 7702 can boost up to 3.35 GHz, check that it >reaches that under load. It actually reaches the frequency under load. Unfortunately, the one core is now fully under load. My Relay moved 5TB today, with an average bandwidth of 500Mbit. The average load according to HTOP is now just over 1.0, which is fine for a dual core. However, one core is loaded to 100%. So far, there are no error messages and I achieve a stable 40MB/s with peaks of up to 50MB/s. But my Relay is only a few days old. Advertised Bandwith is currently at just over 30 MiB, but that will change soon. I'm afraid the CPU won't do much more, but with 500Mbit/s I'm among the fastest Relays at this hoster. Directly on page 1. Let's see if I can tune a bit, otherwise I'll just let it run as long as no errors appear. >Also since you have 2 cores, you can run two instances of Tor. Yes, I know. However, the DirAuths then have more work to do because they have to add another Relay to the Consensus. Everything has advantages and disadvantages. Let's see what I do. >> I chose this server because the bandwith is unmetered and it's a >> guaranteed 1GHz link. >I assume you mean 1 Gbit/s. Yes, that was a typo. By the way, can someone explain to me how to reply directly to a reply in a thread without my reply just appearing at the bottom? I'm new to this list and haven't quite figured it out yet. I hope you understand what I mean - I want my replies to be indented correctly. Thanks! Have a great weekend, everyone! -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEElcZnZFMJSyKcTts0q6Mz3/Qy4d0FAmGO/j0ACgkQq6Mz3/Qy 4d395A/+NDRe7IhCbsmgWCUM2Li1XnoN4g3Z091T+U1QPQg7kCvibXXeiHhgs/jP und/63N7FM3OmHi/WUPerK4qfk5lssRU0OPvyAApIzruCTBDj2TuCdpagsfNRQCU QFE162q/cUvwRDyoNHVXxhSk8Bvtwj6Mxw4oE5p6yJFvBgSjT7uHGZgAgHobs/QH zgCKsoEI3H0Wj8kYtxfP9xlhDe1XNidaGIXe5axFlcraw2/f7LXhG7BPJ2XaQHsp CCPFOoLt3Ggpl3AFyIT/UYJ+2e/y+RJXSy71ptew0Xl3MQXv8j5avpo1zmDFXYqV 4SYbjzqmn/5t/O5QPprTBDVr2+SgkjNoFJWFTFK5R7jjqqGvs9fzbAXV6XGOKBeC F6aRs/caQiJ57gAJmYdUW9dQubeIulR0yUlQlwXWWdAPEduLP3B8MxDtEuFOYHWL h+C3I1tlPp+DFE3hfPARW1hX8DGBtA8pH6MKwn6onJh65mWv6f7pmU8LQHbuPPmw w7o7qZHuXxhFSoxPRklISr0BjcLG94DHGWlD2UMyxpU/m3745+JGHhqlTJX+/aeN HHWJ9FN1beI4YHfeUHBgicEx8pywtHK/l6vi5v9rrzko7nbYwG4SayrsgrpXqz6F ifqCNzouxpjVs7MvuTDPIC62mNLED7Zop3tsMwdnyRZJc8Lm3Uo= =Gm4l -----END PGP SIGNATURE-----

1 0

Question about IPv6
by xplato 12 Nov '21

12 Nov '21

Greetings, I have three relays running Hardened BSD hosted at Frantech. They do not offer support for setting up IPv6. I am not sure how to accomplish this and wondered if anyone would have insight into setting this up? I have not found much in the way of instruction. A resource that provides instructions would be much appreciated. Kindly, Dan Sent with [ProtonMail](https://protonmail.com) Secure Email.

4 3

Re: [tor-relays] Tor website
by failing.flyaway443＠mailer.me 12 Nov '21

12 Nov '21

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi potlatch, is this what you are looking for? https://gitweb.torproject.org/tor.git/tree/src/config/torrc.sample.in https://2019.www.torproject.org/docs/tor-manual.html.en Both links can be found at the bottom of this site: https://support.torproject.org/tbb/tbb-editing-torrc/ I hope this helps... Best regards... 95C6676453094B229C4EDB34ABA333DFF432E1DD -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEElcZnZFMJSyKcTts0q6Mz3/Qy4d0FAmGM5nsACgkQq6Mz3/Qy 4d2QihAAhFAVPRFMdYVokJoRw6kck2kVWO9tJ5/O716UZcCPozHP/ht+RO8GUu5t xF0B3U3tFLtOscnLV8TvhQN0Ngr86IYR3+tD0wxcaiZPj55mD2SMjouxiWdjXHYK fhoGUlw3vM53CeL1QsoCoDcKQHCVMfJZ8NhSA/ME4H9SQl7kkwswmnwwOyOFJ7Wc OM6xTwKddreqkUwWOyCPzaVOj12SjE3gT4LqQjTDYds0c2GWdU4RZUlIFVPA64BD j+p6WJg5wwkgfHA8SNZfAmPg8DYzz+vqbGghnOQbBychugek+bfB4HRn3RgCcxFB s7D50M8jixAOVQDokb7br+xIzN/BxGUfZPD5zgQirjQ/Q2fPx/Xr8EFeYjBlsptI 3k/wqubPGlQpYJkZqrRGQLNVPnQTAwuyWREB/+f6kheoI4Lj84981cRP1XEMh3YB a/L+t84mJaIM8RGi1YoDbhj6Ljmnr57UdOJqev+RnfZjHyxTt1xN6RdsLZxghV8R 9u0MMVNtzhIRci66XUHsREhbm6EzfB/8e1PaX+/TVaX4W/3zprFU9OSoPiBXNYg8 wLeTt3PKFt8bZ6+kmfaM6fDWMiISH5DAGjOtgPU5yoaNlcob2V09DZnWBjE2REPz pebl2NgQad99LK5La5pKkZAawuF/knxfivC0GEj8+0mEAzdPzpk= =tcbs -----END PGP SIGNATURE-----

3 3

Re: [tor-relays] Hardware requirements for a fast Tor relay
by failing.flyaway443＠mailer.me 12 Nov '21

12 Nov '21

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Thank you for your suggestions, Gary. This is actually not a "real" root server, it's a KVM server (of course). The CPU is an AMD EPYC 7702 with 2 dedicated cores per server@3,35GHz. I chose this server because the bandwith is unmetered and it's a guaranteed 1GHz link. I don't think I will ever be able to relay 125MB/s, but I will try my best. If I can only reach ~50MB/s before the CPU starts to grumble I will set up a second Tor process and a second relay. I tuned my relay a bit today, using some of the tips from this conversation: https://lists.torproject.org/pipermail/tor-relays/2010-August/000164.html It's not really up to date, but still useful to some extent. Unfortunately I had to restart the Tor process, but my relay was already measured a few times and reaches spikes of 30MB/s. CPU usage is no issue at all yet, there is room for more. I can wait before I get the guard flag, this is not a race... Thanks again for your help. All the best. PGP-Fingerorint: 95C6676453094B229C4EDB34ABA333DFF432E1DD -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEElcZnZFMJSyKcTts0q6Mz3/Qy4d0FAmGMbCAACgkQq6Mz3/Qy 4d2bpBAAmQIQ6wvjeBhdL4DxPdL9qlxIqbjPMxpPQWWCqSa3x/t+V3mcEzl/Srz7 5hUVwmYwMprtVA9Zf/MDPCElqbs5MpDrHkJE/rGhfEc6ld/Xu62LLVS7US+/ocTb RCLW1WG8pAQymR9avbyDqTqqTBOinIGlxwmCLXAldEllsxfVnKd4nFzxxEv/Ms/4 JrWvnOjJde46CCFchmjEfUGWVgquU9lsjpHbqVz/+ErUKVAd57BmPNpteiXed8xi RuM6BqB5/blL+CmdVISprisaIPIhqlCW5UEkuNPm5ijlrKrBYTSn4/b8HnMdg5UE ynAkzR5dkxyYee+uI84mgIfFNUzaVBpBq2W5obPqGiocoWQKgT70zVPxzLuguyoG U/Mzxikq4K86aorimSad207BEIVkey76s6jqqgKKI7UoTIYUTmc1xsA1tcgi44Me MelT5gEZ/fcesfPpYB/gkIyOIE+ADuCfnvOqDWAOvfnX9q6U9ek8+aHYSXGIdf9M oKjAKkO8Y/BWBsEHlnyBIrfE48/WtSNlQRj9oKSzyFtQs8wDhgoe3mgcvyHnPTOu Tq7UJUGV3L1LHOW6iEZTMKUsD9t1/NpGLpnTgTXne6bYzyJYL4D5w6IX30EaeaPw 387TB7cTj8Vaaw2bTiM7NlfAEdWqxt2v0qcgzFtTSIhnHLGtnQo= =tlZd -----END PGP SIGNATURE-----

2 1

Tor on cloud VPS
by potlatch 12 Nov '21

12 Nov '21

Hello All, My VPS host recently moved one of my Tor exits to cloud ops (I believe AWS). Since that time the instance will not function as an exit. Torcc and keys are as before. I was operating on Ubuntu 21.04 but reloaded to 20.04. Still the same. I messed with the netplan config to no avail. George brought this to my attention and suggested (and I agree) a DNS problem. I can't find where it's failing--to be honest I don't have much experience with cloud instances or netplan. I am of the opinion that there is a conflict between the cloud hosting and Tor. When I call Nyx I see the strange exit policy: reject [FC00:'string of zeros']/7:*, reject [FE80:'string of zeros off of Nyx page']. Other exits I operate are fine in the cloud. Thanks for any help you can provide. potlatch Sent with [ProtonMail](https://protonmail.com/) Secure Email.

2 1

Re: [tor-relays] Tor website
by failing.flyaway443＠mailer.me 11 Nov '21

11 Nov '21

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Sorry, it was not my intention to interfere. $man tor I forgot to mention, that works too of course. Or in this case $man torrc. I already run a relay myself, after several "failed" attempts on cheap VPS now on a root server with unlimited traffic and extremely fast connection. This one: https://metrics.torproject.org/rs.html#details/D1F7BEC34A66498FC565BC057632… I had to take the VPS' offline because they could not handle the traffic I would like to relay. Maybe I'll run a much smaller second relay, I'm still thinking about that. As I said, it was not my intention to provide links to outdated ressources. Won't happen again :) All the best... 95C6676453094B229C4EDB34ABA333DFF432E1DD -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEElcZnZFMJSyKcTts0q6Mz3/Qy4d0FAmGNCJkACgkQq6Mz3/Qy 4d1CLA//UtJzIdphbucuqAY5o4P3K+R4pgqooY9bgsOO9G/A1Ra+hVe2d7yBhESH FnoCsuIAKjBJRX30W8AQIh4R6amwhCLRgrdhacfHFtgjksxKavqXQ3bwS7RfnbZ5 R0V2QDSFyulhwsqIvqKF30WE/Ks3niimQS7nPHzgXRxrBV3yUW0ldw6/tNhS8G+T L6QB0/GuVnZlRat285Y2mx5wX8MAxqoowD3YFI8i1HGEf4IZayyXzQxZobaTlFN9 PcGrZUCgw26N6jDknlpc81ZbX1ZKeeFrcQunl3/LXxE225oASQBoasPmHbTpO2QO wOYbqCJ3eptPZq1e4jvzC0MnBG2nVFH7BcJ4/f7TbrvAhZqxEzvQqHNU/r7s/4Le YzJrEhadxUKESO5W7XGMQdaxlY670JolP1yRL7x3Ese8EgtugKM3BZXMr5w1EAby x6erAiuj+36GEuR8IiXB2bqHJ1GeQmXWOh0lSFdJri9SthF8KYC4jlEvHtvib0wJ NsdaBAEQ2DhgiDtCp9HNDAiDeHf6QanFt+1JGEuKno1HMYzky2rxmYonNcoxfXX0 KnqFKKxn7F78RpTXbioWB4/4MqMUZpV0SWl5LUS/v4zY4B26W9gxQ6/FPGq0a8zs Zeei9AK1gMg+NeFSajC1FSVDncbEEFYKqNryEGMPzrD2b5RVSms= =zzGy -----END PGP SIGNATURE-----

1 0

Tor website
by potlatch 11 Nov '21

11 Nov '21

Hello, Does the new Tor web configuration have an overall site map or index page? I can't find the old page with the manual for torrc. I've had trouble finding other information over the past few weeks as well. Thanks, potlatch Sent with ProtonMail Secure Email.

1 0

A Simple Web of Trust for Tor Relay Operator IDs
by nusenu 10 Nov '21

10 Nov '21

Hi, I wrote down a spec for a simple web of trust for relay operator IDs: https://gitlab.torproject.org/nusenu/torspec/-/blob/simple-wot-for-relay-op… This is related to: https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/iss… https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html kind regards, nusenu -- https://nusenu.github.io

5 9

Crashed Relay
by sysmanager7 10 Nov '21

10 Nov '21

I was notified by Uptime Robot that relay 1 of 3 had been shut down. Unfortunately I found this out 12 hours after the fact. guard flag is lost. journalctl -u tor@default Nov 01 01:03:18 ubuntu-s-1vcpu-2gb-nyc1-01 Tor[328387]: I learned some more directory information, but not enough to build a circuit: We need more microdescrors: we have 6178/6618, and can only build 49% of likely paths. (We have 99% of guards bw, 50% of midpoint bw, and 98% of exit bw = 49% of path bw.) ptors: we have 6178/6618, and can only build 49% of likely paths. (We have 99% of guards bw, 50% of midpoint bw, and 98% of exit bw = 49% of path bw.) ived 4371.61 GB. I've received 7345604 connections on IPv4 and 0 on IPv6. I've made 677780 connections with IPv4 and 0 with IPv6. Nov 01 06:47:26 ubuntu-s-1vcpu-2gb-nyc1-01 Tor[328387]: Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt aga> Nov 01 06:47:26 ubuntu-s-1vcpu-2gb-nyc1-01 Tor[328387]: Delaying directory fetches: We are hibernating or shutting down. Nov 01 06:47:56 ubuntu-s-1vcpu-2gb-nyc1-01 Tor[328387]: Clean shutdown finished. Exiting. Nov 01 06:48:04 ubuntu-s-1vcpu-2gb-nyc1-01 systemd[1]: tor(a)default.service: Succeeded. Nov 01 06:48:04 ubuntu-s-1vcpu-2gb-nyc1-01 systemd[1]: Stopped Anonymizing overlay network for TCP. This is NOT a first time for the above on this relay, more like a 7th or 8th. CPU usage according to NYX is 90/95%. That has been the last three weeks or so. Prior to that, average CPU usage was 30% or less. Current BW/Burst is 3/4 MBs on torrc and nyx. Prior was BW/Burst 4/5 *Me - retired fixed income. Average billing for 3 Digital Ocean Droplets was $40. budget is good with that. Octobers billing - $87.50 I used 10 gb instead of 6Gb. Essentially a $40 overage. It's almost as if, torrc and nyx are being ignored. Sent with [ProtonMail](https://protonmail.com/) Secure Email.

3 2

Re: [tor-relays] Hardware requirements for a fast Tor relay
by failing.flyaway443＠mailer.me 10 Nov '21

10 Nov '21

Hi Gary, thank you for your response. I think I just worry too much. I watched my relay all the time today, I had bandwidth usage of 30MB/s at times and HTOP showed me a Load average of 0.29/0.29/0.30. I know that this is totally fine for a dual core. The relay is up and running for 3 days and 8 hours now and I already moved ~700GB in each direction (upload/download). I was just concerned because the VPS started crashing after 2 weeks solid uptime, but I should have set stricter bandwith limits. You can't really compare a VM with a root server, I don't think this will happen again. It's ok for me to invest a little more and have a fast and stable relay this way. The traffic was capped with the VPS plan, this was obviously a big disadvantage, now I can use as much traffic as I want with a 2,5Gbit link (1Gbit guaranteed). For your info, the most important lines of my config: SocksPort 0 Log notice file /var/log... Log debug file /var/log... ORPort 443 RelayBandwithRate 1000Mbit RelayBandwithBurst 1000Mbit Exit policy reject *:* ContactInfo & Nickname set, of course... ;) Is there anything I should change? Thanks for your help! Best Regards...

2 1

Re: [tor-relays] Hardware requirements for a fast Tor relay
by failing.flyaway443＠mailer.me 10 Nov '21

10 Nov '21

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm sorry that I now spam the mailing list, but I made a mistake. I'm of course NOT logging at debug level, it's just one logfile (notices.log). I logged debug when I was running the relay on the VPS because I wanted to know why it crashed all the time, but all that happened was that my 20TB SSD was maxed out within two hours and I had to reboot to get rid of the old logfiles. My bad, please don't think I write a debug log, that's completely pointless. Why would I. I rented a pretty expensive root server because I think Tor is really important and I want to relay as much traffic as possible, not to log debug messages. This was obviously not correct, but the rest of my torrc looks as described above. By the way, my relay has now around 4000 incoming and 4000 outgoing connections and a throughput of almost 1TB/day, and the load averages are still below .40. Everything looks good. :) Have a nice day, everyone! -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEElcZnZFMJSyKcTts0q6Mz3/Qy4d0FAmGLxa0ACgkQq6Mz3/Qy 4d1vJhAArWytI9hG6iGIvVzUP6lOgLMCEVfn4KBiFzq0iGqr2ex+utWIt8gek3SX Bm9McRbicgDUSzbnrHJrPzKxrpYvvtABbApyDZDSOEwgSXeaUcE2J8jhk20fOA6u tLFf7S+ON88KW8HkwNIkqSFmRifp3dZEBOapFZnBfgREwu19qxg1iyYZfJHDIMd6 4vWzI5oo2D1iFTyCDZllduqEURZNgZRfwtNk8ydfOje9X0QMkHgzy4fECCNgcYdY to+1BbYxY2lT34+1aLoRnnyA2yLykYI2ivRNx+IyD9X/QCKq+3sV+xjRvyOH39r7 Tmvg8NTNuZCiEwi9JCIJlRynrFk3HgUTbCT87iK8PGMTG6TimnBvFKUfKQMwIicD 1YrLQ30hSjTnetRbyLT0B7gd+h+CkDg6ssi0j6eKV0urP6PTipnr19OJeBZ3kZbw j+a3qipxy3mNIp9dW9d+ZBzhV+jtrDUMKUpjqHUkUEEdNH060TSMyYMBwCf7/dgH Ft8FWgTcLtX9dohx/CAHfQ+8rsa/wYEuLnXgc3AXibof9VZaTMKz5iDkhUwOnCoA 0528RNKLH+Rf4CoMOCycjqW0k1svPX9oAXoOgX0GQz/1DnocA4DEs+wVPJmr6dR+ mcHwDiKlOd5ksARl+fivmHurUE+ULzhI8l+Cdhr+Wi7NzVzuZ5U= =s8hY -----END PGP SIGNATURE-----

1 0

Re: [tor-relays] Hardware requirements for a fast Tor relay
by failing.flyaway443＠mailer.me 09 Nov '21

09 Nov '21

I just read this research paper, maybe it's worth thinking about some kind of implementation of this approach some time in the future. It's an interesting read anyway. uwspace.uwaterloo.ca/bitstream/handle/10012/16108/Engler_Steven.pdf Regards

1 0

Hardware requirements for a fast Tor relay
by failing.flyaway443＠mailer.me 09 Nov '21

09 Nov '21

Hi everyone, about two weeks ago, I signed up for a VPS with a cloud provider and set up a Tor relay. I installed Debian 11 Bullseye, secured it, and then set up Tor 0.4.6.8 and started the relay. The VPS had the following specs: 1vCore, 2GB RAM, 40TB traffic per month on a 1Gbit/s link. I throttled the traffic accordingly so that the monthly limit of 40TB would not be exceeded. Nevertheless, the CPU load was extreme, the server was running at full capacity and crashed several times. Since I want to help the Tor network with a fast relay I now signed up for a root server which has the following specs: Dual core CPU, 8GB ECC RAM, 2,5Gbit link, 1Gbit guaranteed, unlimited traffic. I set this thing up with Debian 11 Bullseye again and Tor 0.4.6.8. Since my bandwith gets throttled when I use more than a certain amount of traffic/month and at the same time (!) on average more than a certain amount of bandwith for more than one hour, I set the MaxBandwith to 1000Mbit/sec (equals 125MB/sec). This relay is up and running for a few days now, and I already have around 4000 incoming and outgoing connections. My bandwith is not fully used yet, but sometimes I see spikes of 20MB/s. What concerns me is that the CPU load again is sometimes 40-50% on both cores, even though this relay is not fully used yet. Can somebody tell me if it is even possible to run such a fast relay on this hardware? Should I set a more restrictive bandwith throttle myself, or go for a quad core CPU? I don't think I will ever run out of RAM this time, since I have 8GB. Thank you for your advice! All the best!

2 1

metrics: add `IPv6 Exit Address` in addition to `Exit Address`
by s7r 09 Nov '21

09 Nov '21

Hello, Currently we have Exit Address for relays that use a different IPv4 address for `Exit` connections vs their ORPort IPv4 address. Similarly, one relay *could* listen on a certain IPv6 address ORPort but use a different IPv6 address for v6 exiting. Wouldn't it be useful to add this data too? This would tell us how many relays use one static IPv6 address for ORPort connections and temporary IPv6 addresses for exiting (using IPv6 privacy extensions). By looking at https://metrics.torproject.org/relays-ipv6.html one could assume that almost 50% of the IPv6 enabled relays (IPv6 ORPort) are exits.

1 0

Re: [tor-relays] Max number of bridge under the same IP
by gus 09 Nov '21

09 Nov '21

On Mon, Nov 08, 2021 at 07:02:13PM +0100, ML Tor wrote: > In data 8/11/2021, *gus* ha scritto: > > Hi, > > On Mon, Nov 08, 2021 at 03:24:13PM +0100, ML Tor wrote: > > Hi, > hi made a new Proxmox server for my home network. I still run a bare metal > Tor bridge, but now i would run more bridge in my home network. > > I have a public dynamic IP: what is the max number of bridge i can run > (obviously on different ORPort) under the same IP address > > > From the Tor Relay Guide: > > "Note: You can only run two Tor relays per public IPv4 address. If you > want to run more than two relays you will need more IPv4 addresses." > https://community.torproject.org/relay/relays-requirements/ > > > Too bad, so no more than two bridge on my singe ip. > > But... > > Maybe you want to run a standalone Snowflake > proxy?https://community.torproject.org/relay/setup/snowflake/ > > > Can i run my two bridge AND one Snowflake proxy? ;-) > Yes, it's fine! :) cheers, Gus > Thanks in advance, > > > -- > ML -- The Tor Project Community Team Lead

2 1