tor-relays

tor-relays@lists.torproject.org

42 participants
4821 discussions

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

Expected relay performance
by fugel1 31 Aug '21

31 Aug '21

Hi all! I've been running two tor relays [1] on the same machine for the past three weeks or so on my home connection (1 gigabit fibre). When I was looking for appropriate hardware (I needed something fanless) I was surprised at the almost complete absense of information online about what kind of relay performance one can expect from different cpus. Until the current relays speedtest that started on August 25 [2], my relays were slowly ramping up to about 4 MB/s up and down with a consensus weight of 15-19000. Hence, I was expecting to have to wait a few months to find out what the hardware was capable of, BUT then the mentioned test started! Both my relays instantly got an advertised bandwidth over 70 MB/s, and soon after consensus weights of 85000 and 105000 respectively (maatuska even hade the latter at 190000 for a while). The relays are now pushing over 20 MB/s each which enables me to start filling the current performance information void with the following: A fanless Core i5-8250 with HT disabled, running OPNSense 21.7.1, can push 22 MB/s of tor traffic up and down on each of two tor instances, with each main tor process consuming no more than 50 percent of one core and an average across all cores of 35-38 percent. Sorry about the lengthy post! :) [1] https://metrics.torproject.org/rs.html#details/F387C5F92B784137933202BB5E4F… [2] https://status.torproject.org/experiments/2021-08-26-relay-speed-test/

1 0

Network experiments on the Tor network
by Georg Koppen 25 Aug '21

25 Aug '21

Hello everyone! As you might have seen we had announcements on this list a couple of months back about experiments being run on the live Tor network.[1][2] This shows that our network is quite popular among researchers, which is great. However, it means as well that there are a bunch of questions that might be concerning, like how this in general affects relays, which role the Tor Project should play in this process, how we can be transparent both to our users and our relay community while experiments are running, how we can avoid different experiments, running simultaneously, affecting each other etc. etc. We therefore sat down a bit and wrote up our thoughts and reasoning on a wiki page[3] which is hopefully helping to answer those questions some of you might have. Needless to say, feedback is much appreciated as this document is nothing set in stone. Georg [1] https://lists.torproject.org/pipermail/tor-relays/2021-May/019649.html [2]https://lists.torproject.org/pipermail/tor-relays/2021-May/019672.html [3] https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Network-exper…

1 0

Relay on CentOS8
by Totor be 24 Aug '21

24 Aug '21

Hi all As you might be aware, CentOS is switching from CentOS Linux to CentOS Stream https://www.centos.org/cl-vs-cs/ They provides a straightfowrarw way to migrate from Lunix to Stream: #dnf swap centos-linux-repos centos-stream-repos #dnf distro-sync I have migrated a relay running in a small VM and everything seems to run fine Before migrating my production relay, I would appreciate any feedback from other CentOS users on this migration: disk space required, eventual issues envountered and more generally do's & don'ts Thanks a lot!

2 2

ORPort NoAdvertise & NoListen Not Working
by Gary C. New 24 Aug '21

24 Aug '21

Hi! I'm having issues when implementing the NoAdvertise & NoListen options of the ORPort directive and am hoping someone here might be able to point me in the right direction. I can get Tor to successfully work as a relay without using the NoAdvertise & NoListen options of the ORPort directive, but for certain reasons I need to configure Tor on a Private Address. ### ORPort WITHOUT NoAdvertise & NoListen (SUCCEEDS) ### Note: Successful Self-testing logs WITHOUT NoAdvertise & NoListen Aug 13 00:26:42.000 [notice] Self-testing indicates your ORPort 198.91.60.78:443 is reachable from the outside. Excellent. Publishing server descriptor. Aug 13 00:27:49.000 [notice] Performing bandwidth self-test...done. Note: Successful Self-testing torrc WITHOUT NoAdvertise & NoListen # cat /tmp/torrc Nickname ASUSWRTMerlinRelay ORPort 198.91.60.78:443 SocksPort 9050 SocksPort 192.168.0.1:9050 ControlPort 9051 ExitRelay 0 DirCache 0 MaxMemInQueues 192 MB GeoIPFile /opt/share/tor/geoip Log notice file /tmp/torlog VirtualAddrNetwork 10.192.0.0/10 AutomapHostsOnResolve 1 TransPort 192.168.0.1:9040 DNSPort 192.168.0.1:9053 RunAsDaemon 1 DataDirectory /tmp/tor/torrc.d/.tordb AvoidDiskWrites 1 User tor ContactInfo tor-operator@your-emailaddress-domain Note: Nyx shows Tor build the initial 5 measurement circuits and then successfully continues to build new circuits # nyx nyx - gnutech-wap01 (Linux 2.6.36.4b...) Tor 0.4.5.7 (recommended) ASUSWRTMerlinRelay - 198.91.60.78:443, Control Port (open): 9051 cpu: 30.4% tor, 62.1% nyx mem: 53 MB (21.4%) pid: 14372 uptime: 05:18 fingerprint: 02DD61E41B3739C629C5CF8CEBA6000290BC3E7B flags: Fast, Running, Valid page 2 / 5 - m: menu, p: pause, h: page help, q: quit Connections (807 outbound, 9 circuit, 1 control): Note: Openssl s_client is successfully CONNECTED to the Public Address # openssl s_client -connect 198.91.60.78:443 CONNECTED(00000003) depth=0 CN = www.uy24fd6wkrzss.net verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = www.uy24fd6wkrzss.net verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=www.uy24fd6wkrzss.net i:/CN=www.bu5cm42gttwqzick.com --- Server certificate -----BEGIN CERTIFICATE----- MIICQzCCAaygAwIBAgIJAOPPF6uxLfr8MA0GCSqGSIb3DQEBCwUAMCMxITAfBgNV BAMMGHd3dy5idTVjbTQyZ3R0d3F6aWNrLmNvbTAeFw0yMTAzMDEwMDAwMDBaFw0y MTA5MjUwMDAwMDBaMCAxHjAcBgNVBAMMFXd3dy51eTI0ZmQ2d2tyenNzLm5ldDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM/1zzI/PdYXIm6p1ZshOzIf AnUfauCPovIutPWBBNi9Q6um6EWYzb7DIKhmiTwijl691ktfylwVIMT8JnGO+1t1 +SooiSp4V1oSkMvoA0Whvhh3jonblvq7cD0FGz9xLVxJEs4I5LPxxDFDcfs5AHV9 wQ1rH+CnGOlBGD2X3jjOVJb1Vp9PZPj5sG4mCyBIfJdbuC1MYkXoOfmi8kY0MkV8 mB/XAODk4GmDTPG76gxAv3Da+10vcABqMNpSwraFZwcBcGOhUnmpKxRmm2dZdz7r tTLcZaaeAYJlNH4fxoG6PdmcPidLnlT4ILX44cXAf+OL4WJgWrRUUexTpI75pW0C AwEAATANBgkqhkiG9w0BAQsFAAOBgQCB9fjVciHTD0YlckPoSTzZJXHkDaBpmBVa 9/GpVLQMA9bK03AkDllycxEbSgB0bd8RjZKd1+3T7ck2FsOOzgIZP0v5U8A0uxA7 58w2yJWmomn9DaKXqwD9HHux905znq3elKzd1M5ZSbQhZdqNmsw8wZUo2ZaPCDHW wBCd2m6Ueg== -----END CERTIFICATE----- subject=/CN=www.uy24fd6wkrzss.net issuer=/CN=www.bu5cm42gttwqzick.com --- No client certificate CA names sent Peer signing digest: SHA256 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 1058 bytes and written 428 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: Session-ID-ctx: Master-Key: BC7B6CA79A1466768EAE37C7D591FB57F2D351E75B4C43AB16C8B8CBCBEB8E4BA4EDE2FEED8D4036D045F42F3F029585 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1628842910 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- However, Tor fails to work as a relay using the NoAdvertise & NoListen options of the ORPort directive; even though, Openssl s_client is successfully CONNECTED to the Public Address. ### ORPort WITH NoAdvertise & NoListen (FAILS) ### Note: Failed Self-testing logs WITH NoAdvertise & NoListen Aug 13 01:01:46.000 [notice] Now checking whether IPv4 ORPort 198.91.60.78:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) Aug 13 01:21:45.000 [warn] Your server has not managed to confirm reachability for its ORPort(s) at 198.91.60.78:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Note: Failed Self-testing torrc WITH NoAdvertise & NoListen # cat /tmp/torrc Nickname ASUSWRTMerlinRelay ORPort 198.91.60.78:443 NoListen ORPort 192.168.0.1:9001 NoAdvertise SocksPort 9050 SocksPort 192.168.0.1:9050 ControlPort 9051 ExitRelay 0 DirCache 0 MaxMemInQueues 192 MB GeoIPFile /opt/share/tor/geoip Log notice file /tmp/torlog VirtualAddrNetwork 10.192.0.0/10 AutomapHostsOnResolve 1 TransPort 192.168.0.1:9040 DNSPort 192.168.0.1:9053 RunAsDaemon 1 DataDirectory /tmp/tor/torrc.d/.tordb AvoidDiskWrites 1 User tor ContactInfo tor-operator@your-emailaddress-domain Note: Confirmed that the necessary PortForward between the Public & Private Addresses is in place # iptables -t nat -S | grep :9001 -A VSERVER -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.0.1:9001 Note: Nyx shows Tor build the initial 5 measurement circuits, but after some time fails and only shows the outbound & control connections. # nyx nyx - 192.168.0.1 (Linux 2.6.36.4b...) Tor 0.4.5.7 (recommended) ASUSWRTMerlinRelay - 192.168.0.1:9001, Control Port (open): 9051 cpu: 10.6% tor, 3.2% nyx mem: 55 MB (22.2%) pid: 5374 uptime: 56:32 fingerprint: 02DD61E41B3739C629C5CF8CEBA6000290BC3E7B flags: Fast, Running, Valid page 2 / 5 - m: menu, p: pause, h: page help, q: quit Connections (2289 outbound, 1 control): Note: Openssl s_client is successfully CONNECTED to the Public Address # openssl s_client -connect 198.91.60.78:443 CONNECTED(00000003) depth=0 CN = www.uy24fd6wkrzss.net verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = www.uy24fd6wkrzss.net verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=www.uy24fd6wkrzss.net i:/CN=www.bu5cm42gttwqzick.com --- Server certificate -----BEGIN CERTIFICATE----- MIICQzCCAaygAwIBAgIJAOPPF6uxLfr8MA0GCSqGSIb3DQEBCwUAMCMxITAfBgNV BAMMGHd3dy5idTVjbTQyZ3R0d3F6aWNrLmNvbTAeFw0yMTAzMDEwMDAwMDBaFw0y MTA5MjUwMDAwMDBaMCAxHjAcBgNVBAMMFXd3dy51eTI0ZmQ2d2tyenNzLm5ldDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM/1zzI/PdYXIm6p1ZshOzIf AnUfauCPovIutPWBBNi9Q6um6EWYzb7DIKhmiTwijl691ktfylwVIMT8JnGO+1t1 +SooiSp4V1oSkMvoA0Whvhh3jonblvq7cD0FGz9xLVxJEs4I5LPxxDFDcfs5AHV9 wQ1rH+CnGOlBGD2X3jjOVJb1Vp9PZPj5sG4mCyBIfJdbuC1MYkXoOfmi8kY0MkV8 mB/XAODk4GmDTPG76gxAv3Da+10vcABqMNpSwraFZwcBcGOhUnmpKxRmm2dZdz7r tTLcZaaeAYJlNH4fxoG6PdmcPidLnlT4ILX44cXAf+OL4WJgWrRUUexTpI75pW0C AwEAATANBgkqhkiG9w0BAQsFAAOBgQCB9fjVciHTD0YlckPoSTzZJXHkDaBpmBVa 9/GpVLQMA9bK03AkDllycxEbSgB0bd8RjZKd1+3T7ck2FsOOzgIZP0v5U8A0uxA7 58w2yJWmomn9DaKXqwD9HHux905znq3elKzd1M5ZSbQhZdqNmsw8wZUo2ZaPCDHW wBCd2m6Ueg== -----END CERTIFICATE----- subject=/CN=www.uy24fd6wkrzss.net issuer=/CN=www.bu5cm42gttwqzick.com --- No client certificate CA names sent Peer signing digest: SHA256 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 1058 bytes and written 428 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: Session-ID-ctx: Master-Key: BC7B6CA79A1466768EAE37C7D591FB57F2D351E75B4C43AB16C8B8CBCBEB8E4BA4EDE2FEED8D4036D045F42F3F029585 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1628842910 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- What am I missing? Am I implementing the NoAdvertise & NoListen options of the ORPort directive incorrectly? Thank you for your assistance. Respectfully, Gary

3 6

Tor non-exit relays and Hulu in 2021
by Neel Chauhan 18 Aug '21

18 Aug '21

Hi tor-relays@, Long time no see. Lately I'm more involved with the FreeBSD community, but I still run Tor relays though! I'm moving into a new house in Seattle, WA which has CenturyLink Fiber. However, I'm moving in with people who watch Hulu. I remember Hulu blocked Tor middle relay IPs back in 2016-7, but haven't seen recent information on this. Does Hulu still block Tor middle relay IPs in 2021? I'm also considering adding a static IP block but not sure if CenturyLink is willing to give static IPs to me. I signed up for a "business" account but since it's a "residential" address CL's systems may not 'allow' this [1], so that's why I'm asking. Comcast is not an option for me despite technically being "available" for obvious well-documented reasons. After all, CenturyLink is giving me 1 Gbps Fiber, not 1.5 Mbps DSL. -Neel Chauhan === FOOTNOTES === [1] - https://www.reddit.com/r/centurylink/comments/p6cs1t/cbrasstatic_ip_block_w…

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays