tor-relays March 2022

tor-relays@lists.torproject.org

44 participants
33 discussions

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

Auto-discovered IPv6 address [...] has not been found reachable.
by Onion Operator 11 Mar '22

11 Mar '22

Hi Need another couple of eye balls on my relay, RealityLeighWinner. I keep reading "Auto-discovered IPv6 address [2a02:a446:5ef1:1:d072:53ff:fef4:ea59]:443 has not been found reachable..." in the logs but I actually can reach it with openssl s_client from another ipv6 box not in the same network. Could please anybody double check and maybe explain this behavior? Thanks. Oo.

2 1

Ansible role to deploy Bridges
by Erasme - Relay Operator 09 Mar '22

09 Mar '22

Hi all, In the effort of deploying obfs4 bridges for the community we are sharing our Ansible role that allowed us to deploy multiple nodes: https://github.com/NewNewYorkBridges/ansible-tor-bridge For now it is only available on Debian but we will make it available for other distributions. We hope this role is helpful for the community. Feel free to send us your feedback! Kind regards, Erasme

3 2

Relay Finger Print Mismatch Error
by Peligro 08 Mar '22

08 Mar '22

Hello Everyone, I started running a relay, recently and it got up for 3 days became middle node and suddenly stopped. I am not sure what was happened, In logs i found that finger print mismatch error. so i tried to find is there any related post or blog but i couldn't found any, please help me on this to get back relay community. Very Happy using tor, want contribute to community Thanks Peligro

3 2

Good hosting providers for an exit node
by Charles Bevitt 07 Mar '22

07 Mar '22

I run a middle relay at home but now I’m planning to also lease a VPS to run an exit node. I’d appreciate any suggestions for a good hosting provider. My first choice would have been BUYVM, but it seems they’re always out of stock. This will be my first time working with a VPS and Linux, so wish me luck! Chuck Bevitt Sent from my iPad

3 2

FreeBSD DNS/tor version question
by George 07 Mar '22

07 Mar '22

At Saturday's relay ops events, someone had issues with a FreeBSD relay. I believe the issues were related to DNS and the tor version. Please feel free to raise those questions here, or on IRC at #tor-relays. g

1 0

New bridge IN Russia?
by a tor op 06 Mar '22

06 Mar '22

Hi, I am thinking of starting another bridge. In regards to the current situation, is there a real benefit in deploying one within Russia or does that really not matter? A tor op

2 1

rdsys was ignoring BridgeDistribution
by meskio 05 Mar '22

05 Mar '22

As mentioned before[0] BridgeDB now uses rdsys as backend. I just found out that there was a bug in rdsys and the BridgeDistribution configuration was ignored. Private bridges configured with 'BridgeDistribution none' might have being distributed by bridgedb if they were not configured with 'PublishServerDescriptor 0'. Disabling PublishServerDescriptor stops the bridge from sending it's descriptor to the bridge authority, so rdsys doesn't know it exists. Other bridges configured to be used by an specific distributor might have being distributed by a different one. This has being happening from February 28th ~12:00UTC until today March 4 ~12:00UTC. You can search for your hashed fingerprint in the pool assignments during this period if you want to know to what distributor was your bridge assigned to: https://metrics.torproject.org/collector/recent/bridge-pool-assignments/ Only bridges assigned to moat, email or https might have being distributed, as telegram, settings and reserved bridges are not distributed at the moment. The metrics relay search[1] will take some time to display the new assignments. I'm sorry for the situation. [0] https://lists.torproject.org/pipermail/tor-relays/2022-February/020365.html [1] https://metrics.torproject.org/rs.html -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays March 2022