September 2021 - tor-relays - lists.torproject.org

new tor network graphs on OrNetStats
by nusenu 10 Sep '21

10 Sep '21

Hi, up until now OrNetStats mainly consisted of tables with lots of numbers about tor network stats that can be interactively searched, but graphs are usually a lot easier to comprehend, that is why I'll be adding more graphs to OrNetStats. Today I've added the first new graph on the main page that shows the 10 largest proven exit operator domains and their exit fraction in a bar chart: https://nusenu.github.io/OrNetStats/index.html In the long run I plan to publish (and re-implement) all graphs that currently are nonpublic (and not on OrNetStats yet). This should give more people a better view / understanding about what is happening/changing on the tor network infrastructure. kind regards, nusenu -- https://nusenu.github.io

1 0

Relay Control Port
by sysmanager7 10 Sep '21

10 Sep '21

In torrc I have the control port commented out. I'm told the control port is not supposed to be listed on the relay itself. Below, is now what it says. How do I get rid of it? Control Socket: /run/tor/control GroupWritable RelaxDirModeCheck Thank you for your help :-) Sent with [ProtonMail](https://protonmail.com/) Secure Email.

3 2

Burning Bridges
by torix 10 Sep '21

10 Sep '21

I think I remember Roger Dingledine saying somewhere that bridges' ips gradually get learned and put on ban lists. I have some bridges bought for the year. When renewal time comes up, does it make sense to let them go and buy new vms for the next year rather than renew them? I don't know if it matters what pool a bridge is in. TIA, --Torix Sent with [ProtonMail](https://protonmail.com/) Secure Email.

2 1

router_do_orport_reachability_checks()
by Gary C. New 10 Sep '21

10 Sep '21

All: Does anyone here know the procedure of the router_do_orport_reachability_checks() function? I've increased logging of my Tor Relay to info and taken several packet-captures, but can't seem to identify connections initiated by my Tor Relay when verifying my ORPort reachability. I just see connections from other Tor Relays initiate connections with my Tor Relay. Any detail that can be provided regarding the procedure of the router_do_orport_reachability_checks() function is greatly appreciated. Respectfully, Gary

1 1

>50% tor exit capacity is now safer against ContactInfo impersonation attacks
by nusenu 09 Sep '21

09 Sep '21

Hi, when analyzing unusual activities on the tor network one of the problems always was the fact that tor relay ContactInfos are an unverifiable claim. This has been exploited by malicious entities multiple times to setup malicious relays using other people's contact details. Since the release of the ContactInfo Information Sharing Specification (version 2) in October 2021 there is an easy option to setup ContactInfo strings that contain a non-spoofable domain to address this issue. https://lists.torproject.org/pipermail/tor-relays/2020-October/019024.html By now over 900 tor relays have set a verifiable domain in their ContactInfo, and this week the landmark of 50% of the tor network's exit capacity has been reached. graph: https://nusenu.github.io/OrNetStats/exit-fractions (since so many operators implemented the spec the mouse-over on that graph is a bit overwhelmed - I'll fix that soon-ish :) It is important to note that a verifiable domain in a ContactInfo string does _not_ mean "this relay is certainly not malicious" after all malicious relay operators can setup verified domains as well with a domain under their control, but having non-spoofable operator identifiers are the foundation for operator trust based relay selection. It is easier to say "I trust www.quintex.com to operate relays without malicious intend" than to say "I trust CC14C97F1D23EE97766828FC8ED8582E21E11665,DE4F7A7B2DF8689B1F8D23ABA9E320D17638EAFD, ..." because relay fingerprints are not human readable and are more likely to change over time. In case you want to join the effort or simply would like to see your operator level graphs - a nice side effect (example: https://nusenu.github.io/OrNetStats/hydra-family.github.io.html) here is the short version on how to set a verifiable domain in your ContactInfo: https://mastodon.social/@nusenu/106094297537909911 Thanks to everyone who joined so far and indirectly helps with malicious relay analysis! kind regards, nusenu -- https://nusenu.github.io

1 0

Old version in Debian/Ubuntu repo?
by Eric Jacksch 05 Sep '21

05 Sep '21

Greetings, Just a heads-up that a fresh install on Ubuntu 20.04 as per https://community.torproject.org/relay/setup/guard/debianubuntu/ Results in a version warning in the log file: "Please upgrade! This version of Tor (0.4.2.7) is not recommended, according to the directory authorities. Recommended versions are: ...." Cheers, Eric

2 2

Did obfs4proxy stopped working for you on Debian Buster or Bullseye?
by s7r 03 Sep '21

03 Sep '21

Hello, Did you try running obfs4proxy on Debian Buster or Bullseye and it worked? For me it stopped working entirely. All it says is: [warn] Pluggable Transport process terminated with status code 256 Here is what I checked so far: - I am on Debian Bullseye with all packages up to date - go lang version is go1.15.9 linux/amd64 - obfs4proxy version is obfs4proxy-0.0.12-dev (compiled from git) - Tor version is 0.4.7.0-alpha-dev I have edited /lib/systemd/system/tor(a)default.service & tor@.service to NoNewPrivileges=no and also installed libcap2-bin and setcap +ep to obfs4proxy executable. The libcap2-bin step is because I want to bind to a lower port, but even if I try to bind to a higher port like 50001 it will still not work and report the same: Pluggable Transport process terminated with status code 256. On another server I did a software upgrade from stretch to buster by apt dist upgrade and obfs4proxy stopped working as well. I am still digging here cause there are chances I did some mistakes while upgrading, so I am just mentioning the Bullseye problem because there are no excuses there, it should work, it's a clean fresh new install from scratch. Can someone please have another look to see if the problem is just on my side or if it's persistent among Bullseye installs, we should update the wiki bridge howto. Thanks.

1 2

Inflated throughput measures from torproject metrics?
by torix 02 Sep '21

02 Sep '21

The advertized bandwidth of my aramis family of relays has gone up from around 45 to 67 total since last week. ZimmerLinux (quetzalcoatl) sees inflation as well. I found a graph here of quetzalcoatl: https://nusenu.github.io/OrNetStats/quetzalcoatl-relays.org.html which whose weekly graph currently shows everything staying the same until about Wed. 25 Aug., then creeping up. He hasn't added any relays, so it looks as though the bwauths have changed something. I'm bringing this up because something seems a little out of control here. TIA, --Torix

2 6