- tor-relays - lists.torproject.org

Newbie needs help
by tdukes＠palmettoshopper.com 22 Mar '22

22 Mar '22

Hi, Thanks for adding me to the list. I setup a Tor Relay in Docker using this image: https://hub.docker.com/r/doudou34/tor-server Its running, so how can I test it? When I try to access it using port 9001, I'm unable to connect. I have opened the port on my firewall to the public. Haven't done it on my router yet but I have Portainer running in Docker and have no problem accessing it. Not a lot of instructions that I can find. I can post the torrc file but it's the same as the one on the docker page. ### /etc/torrc ### # see /etc/torrc/torrc.default and https://www.torproject.org/docs/tor-manual.html.en # Server's public IP Address (usually automatic) #Address 10.10.10.10 # Port to advertise for incoming Tor connections. # common ports are 9001, 443 ORPort 9001 # Mirror directory information for others (optional) # common ports are 9030, 80 #DirPort 9030 # Run as a relay only (not as an exit node) ExitPolicy reject *:* # no exits allowed # Set limits #RelayBandwidthRate 1024 KB # Throttle traffic to #RelayBandwidthBurst 2048 KB # But allow bursts up to #MaxMemInQueues 512 MB # Limit Memory usage to # Run Tor as obfuscated bridge #ServerTransportPlugin obfs3 exec /usr/bin/obfsproxy managed #ServerTransportListenAddr obfs3 0.0.0.0:54444 #BridgeRelay 1 # Run Tor only as a server (no local applications) SocksPort 0 # Run Tor as a regular user (do not change this) User debian-tor DataDirectory /var/lib/tor # If no Nickname or ContactInfo is set, docker-entrypoint will use # the environment variables to add Nickname/ContactInfo here #Nickname Tor4 # only use letters and numbers #ContactInfo email(a)example.org I've only been using docker for a few days, so maybe its an issue there. TIA

4 4

Bridge on two port
by binarynoise 21 Mar '22

21 Mar '22

Hello everyone, I currently run a bridge on port 8080. As I don't have a webserver running, I thought I'd also publish that bridge on port 443. For relays there is that "ORPort 443 NoListen"-Option. What is the equivalent for ServerTransportListenAddr? Is ServerTransportListenAddr obfs4 0.0.0.0:443 NoListen the right way? Is this possible at all? Does make running a bridge on two ports make sense at all? Greetings binarynoise

1 0

Tor 0.3.5.x is unsupported, please upgrade
by Georg Koppen 21 Mar '22

21 Mar '22

Hello! It's time again to get relays upgraded running an EOL Tor series (0.3.5.x). We'll start reaching out to operators with valid contact information this week and plan to start reject relays which are still on 0.3.5.x about 4 weeks from now on at the begin of March. You can follow along that process in our bug tracker[1] if you want. For the general processes around dealing with EOL relays in the Tor network see my mail from last October[2]. Feedback and improvements are welcome, as always. Georg [1] https://gitlab.torproject.org/tpo/network-health/team/-/issues/171 [2] https://lists.torproject.org/pipermail/tor-relays/2021-October/019862.html

1 1

Connection burst
by Felix 21 Mar '22

21 Mar '22

Hi everybody Just to let you know. Yesterday between 21:26 and 21:31 utc the relay 03C3069E814E296EB18776EB61B1ECB754ED89FE (Tor 0.4.7.4-alpha, LibreSSL 3.4.2) received a connection burst of 2k+ source addresses out of 174 /8 ip4 nets (1-223/8). They were kicked off by the packetfilter because the max conn per ip rate was above my applied max threshold. The notice level DoS mitigation entry remained untouched while sitting behind the pf. Beautiful! -- Cheers Felix

2 1

Which is the most useful: relay or bridge
by Thoughts 19 Mar '22

19 Mar '22

Currently running both a guard relay and a bridge, one each on two different systems, but both behind the same firewall and static IP. Curious if this is a good idea, or if one or the other is of much greater value. Seeing about 2200 inbound, 2800 outbound connections on my relay per nyx, with an observed speed of 5 MB/s (only a few days into the guard ramp-up phase) Seeing about 20 connected clients on the bridge, which is advertising 2.2 MiB/s per the metrics page. R/W rates around around 150k per that same page, about 1/4th of the average on the guard relay. Thoughts?

4 4

What is the current method of submitting Tor-friendly ISPs for consideration?
by Isaac Grover, Aileron I.T. 18 Mar '22

18 Mar '22

Good afternoon from Wisconsin, Following up on a previous post to this list, I started contacting AS administrators in bulk and currently have five ISPs in unique ASs who state they can accommodate Tor exit nodes. The GoodBadISPs page on TP.o doesn't have a submission form or contact email address where I can submit the relevant info. Should I post them here or is there a better/preferred method? Thank you in advance, Isaac Grover

2 1

Possible compression bomb
by Tschador 18 Mar '22

18 Mar '22

Hi, today I found this message in my Tor relay log: Mar 17 14:26:17.000 [warn] Possible compression bomb; abandoning stream. Mar 17 14:26:17.000 [warn] Unable to decompress HTTP body (tried Zstandard compressed, on Directory connection (client reading) with 86.59.21.38:80). What does it mean? Regards

1 0

Re: [tor-relays] Auto-discovered IPv6 address [...] has not been found reachable.
by Onion Operator 14 Mar '22

14 Mar '22

> Fran wrote: > Hej, Hello, > > TLS handshake succeeds for me from my laptop: > > $ curl --insecure https://[2a02:a446:5ef1:1:d072:53ff:fef4:ea59] -v > * Trying 2a02:a446:5ef1:1:d072:53ff:fef4:ea59:443... > * Connected to 2a02:a446:5ef1:1:d072:53ff:fef4:ea59 > (2a02:a446:5ef1:1:d072:53ff:fef4:ea59) port 443 (#0) > * ALPN, offering h2 > * ALPN, offering http/1.1 > * TLSv1.3 (OUT), TLS handshake, Client hello (1): > * TLSv1.3 (IN), TLS handshake, Server hello (2): > * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): > * TLSv1.3 (OUT), TLS handshake, Client hello (1): > * TLSv1.3 (IN), TLS handshake, Server hello (2): > * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): > * TLSv1.3 (IN), TLS handshake, Certificate (11): > * TLSv1.3 (IN), TLS handshake, CERT verify (15): > * TLSv1.3 (IN), TLS handshake, Finished (20): > * TLSv1.3 (OUT), TLS handshake, Finished (20): > * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 > * ALPN, server did not agree to a protocol > * Server certificate: > * subject: CN=www.s5uu2cs3ui4yok4.net > * start date: Nov 2 00:00:00 2021 GMT > * expire date: Apr 16 00:00:00 2022 GMT > * issuer: CN=www.yi5r3anmk2gd3fbqrw4.com > * SSL certificate verify result: unable to get local issuer certificate (20), > continuing anyway. >> GET / HTTP/1.1 >> Host: [2a02:a446:5ef1:1:d072:53ff:fef4:ea59] >> User-Agent: curl/7.82.0 >> Accept: */* >> > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): > * old SSL session ID is stale, removing > ^C > > What if you configure the IPv6 address by hand in torrc? for months my torrc had ORPort 443 IPv4Only ORPort [2a02:a446:5ef1:1:d072:53ff:fef4:ea59]:443 IPv6Only Address XXX and read in the logs: Unable to find IPv6 address for ORPort 443. You might want to specify IPv4Only to it or set an explicit address or set Address. (XXX had only the A record) > > Can you please send your torrc and the output of --- cut here --- ContactInfo flev @ kpnmail . nl Nickname RealityLeighWinner ExitPolicy reject *:* ExitPolicy reject6 *:* AvoidDiskWrites 1 DirPort 80 ORPort 443 Address XXX --- cut here --- where XXX is a DNS entry with both A and AAAA records. > > ip route show table all default via 192.168.2.254 dev eth0 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.102 broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1 local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 broadcast 192.168.2.0 dev eth0 table local proto kernel scope link src 192.168.2.102 local 192.168.2.102 dev eth0 table local proto kernel scope host src 192.168.2.102 broadcast 192.168.2.255 dev eth0 table local proto kernel scope link src 192.168.2.102 ::1 dev lo proto kernel metric 256 pref medium 2a02:a446:5ef1:1::/64 dev eth0 proto kernel metric 256 expires 257593sec pref medium fe80::/64 dev eth0 proto kernel metric 256 pref medium default via fe80::7e39:53ff:fef6:d2cc dev eth0 proto ra metric 1024 expires 1464sec hoplimit 64 pref medium local ::1 dev lo table local proto kernel metric 0 pref medium local 2a02:a446:5ef1:1:d072:53ff:fef4:ea59 dev eth0 table local proto kernel metric 0 pref medium local fe80::d072:53ff:fef4:ea59 dev eth0 table local proto kernel metric 0 pref medium multicast ff00::/8 dev eth0 table local proto kernel metric 256 pref medium > ip address show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether d2:72:53:f4:ea:59 brd ff:ff:ff:ff:ff:ff permaddr 00:1e:06:42:f9:14 inet 192.168.2.102/24 brd 192.168.2.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2a02:a446:5ef1:1:d072:53ff:fef4:ea59/64 scope global dynamic mngtmpaddr valid_lft 257524sec preferred_lft 171124sec inet6 fe80::d072:53ff:fef4:ea59/64 scope link valid_lft forever preferred_lft forever BTW, it's also silly that the DirPort seems not effective. I can reach it from outside but don't get it in the descriptor. This the output of ss -plt: LISTEN 0 4096 0.0.0.0:80 0.0.0.0:* users:(("tor",pid=992,fd=9)) LISTEN 0 4096 127.0.0.1:9050 0.0.0.0:* users:(("tor",pid=992,fd=6)) LISTEN 0 4096 0.0.0.0:443 0.0.0.0:* users:(("tor",pid=992,fd=7)) LISTEN 0 4096 [::]:443 [::]:* users:(("tor",pid=992,fd=8)) > > tnx & ciao, > fran thanks Oo.

2 2

Moving Bridges
by Eddie 12 Mar '22

12 Mar '22

One of my bridges has just taken on a slew of new connections. Over the last few days it's gone from an average of around 15 users to over 300 (according to tor metrics. The logs show over 1,000 unique clients for the same period). Unfortunately with the VPS provider I'm using, this isn't sustainable as I'll probably blow my bandwidth allowance in a matter of days and the excess charges are crazy. So I'm looking to move both my bridges to a new VPS, which unfortunately is probably going to p!ss off the 300 plus folks who have just found my bridge only for it to promptly disappear, as I'm certain that there's no way to "move" them to the new location and have a couple of questions. I'm guessing that the only advantage in copying over the keys directory is that the historical statistics will remain. Is there any reason to copy over the pt_state directory, to retain the same bridgeline information. Cheers.

4 5

Flooding of unbound via resolve attempts
by Georg Koppen 11 Mar '22

11 Mar '22

Hello! As you might know we are doing regular (at the moment weekly) scans of exit nodes to find and help with misconfigurations or errors that have potentially serious effects for Tor network usability and performance. The results we got so far after over a year of scanning are roughly single digit numbers of exit relays per week having mostly DNS configuration issues (unbound crashed etc.) However, this week we suddenly found almost 80 exit relays with malfunctioning DNS resolution[1] which was surprising. Additionally, after some of the servers got fixed the issue returned. DrWhax (thanks!) pointed us to a possible explanation twittered by the unredacted folks: https://twitter.com/unredacted_org/status/1501458345219215363 It seems that someone (intentionally or not) is overwhelming unbound leading to DNS resolution issues for those exit operators that do run this local resolver, which we currently recommend. We've opened a ticket[2] for further investigation, but I hope this email raises some awareness so that exit operators can keep and eye on the situation. Feel free to add insights you have to the ticket. Additionally, I bet if someone would share how they do monitoring for such a problem on their exits then a lot of exit operators would be happily picking up that setup and the Tor network would win. :) Thanks, Georg [1] https://gitlab.torproject.org/tpo/network-health/team/-/issues/197 [2] https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/30

3 2