- tor-relays - lists.torproject.org

OrNetStats now parses all your ContactInfo v2 fields and warns you if your Tor version is vulnerable
by nusenu 15 Sep '21

15 Sep '21

today I pushed new features to OrNetStats: https://nusenu.github.io/OrNetStats/ - Relay Search replacement: relay level pages via a custom allium[1] version Thanks to Jordan for creating allium! - parse and display all ContactInfo v2 fields [2] example: https://nusenu.github.io/OrNetStats/w/relay/A14D96E6C4C3A5AF3D7E57AC0A85AE8… - proven operator domains are highlighted with an icon in all overview relay lists (family-, contact-, country-level pages) example: https://nusenu.github.io/OrNetStats/w/misc/families-by-bandwidth.html (we display the proven operator domain instead of the ContactInfo when available) - the icon links directly to the proof file from the operator (on the relay-level page) - we display a warning sign when a relay runs a vulnerable version of tor examples on relay and contact-level pages: https://nusenu.github.io/OrNetStats/w/relay/FB58E117D11F87F0A291475D603EC61… https://nusenu.github.io/OrNetStats/w/contact/17b90573a94e713bf1b3ad7988934… - we display bandwidth in G|Mbit/s not MByte/s - onionoo AS data replaced with ipfire's upstream version: we no longer use AS data from onionoo - which made the switch from previously used https://yui.cat links to a custom allium version necessary because yui.cat (allium) uses onionoo as data source. Previously over 2000 relays had no AS name data (which affected >25% of tor's exit capacity). Now we are down to bellow 0.1% affected exit capacity without AS name data (mainly in the LACNIC region). +------------+--------+-----------+ |date |affected| affected | | | relays | exit_prob | +------------+--------+-----------+ ... | 2021-09-06 | 2005 | 24.03 | | 2021-09-07 | 2025 | 27.33 | | 2021-09-09 | 2038 | 27.93 | | 2021-09-10 | 2045 | 28.45 | | 2021-09-11 | 2041 | 28.12 | | 2021-09-12 | 2045 | 28.70 | | 2021-09-13 | 2044 | 27.32 | | 2021-09-14 | 2029 | 26.44 | | 2021-09-15 | 108 | 0.05 | <<< todays switch from onionoo to ipfire +------------+--------+-----------+ kind regards, nusenu [1] https://github.com/tempname1024/allium [2] https://nusenu.github.io/ContactInfo-Information-Sharing-Specification -- https://nusenu.github.io

1 0

IPv6 reachability tests fail on CenturyLink IPv6 6rd - reachability broken?
by Neel Chauhan 13 Sep '21

13 Sep '21

Hi, I recently moved into a home with CenturyLink Fiber and moved my FreeBSD relays to the said home. Fingerprints: https://metrics.torproject.org/rs.html#details/B0F9BA27944FA59E3B1A182208FF… https://metrics.torproject.org/rs.html#details/DB710B14D7329B7289CFCC547F48… In my relay logs, while IPv4 works fine, I get these IPv6 errors: Aug 26 18:47:01.000 [notice] Auto-discovered IPv6 address [REDACTED]:143 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. Aug 26 19:47:01.000 [notice] Auto-discovered IPv6 address [REDACTED]:143 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 2400 seconds] CenturyLink does use 6rd for IPv6 in case that matters, however I can telnet the relay ORPort via IPv6 from a VPS. My firewall is an OPNsense box which terminates PPPoE/6rd. I am running tor-0.4.6.4-rc. Yes I know it's not the "latest", but I usually run the "beta" versions on my relays from FreeBSD pkg. Rebooting both my OPNsense box and my server doesn't work. The same relay fingerprints/torrcs/keys worked fine on Google Fiber/Webpass native IPv6 in another address. I'm guessing IPv6 reachability tests aren't working right now since it worked with CL 6rd earlier today, or maybe CL misconfigured their network. It's not a biggie for me, but while I could go Comcast with better IPv6, I'd rather have a high bandwidth relay than an IPv6 one with Comcast's slow uploads/caps. Other Seattle ISPs like Webpass, Wave, and Atlas aren't in my new home. -Neel Chauhan === https://www.neelc.org/

2 1

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