- tor-relays - lists.torproject.org

obfs4 bridge management
by Christopher Sheats 10 Dec '23

10 Dec '23

Hello, I've has published a shell script for deploying and managing obfs4 bridges, I hope its useful to others. https://github.com/emeraldonion/bridge-management/ Feedback welcome! -- yawnbox https://disobey.net/@yawnbox https://digitalcourage.social/@EmeraldOnion

1 0

Exit operators on the 0.4.8.x series, please upgrade to 0.4.8.10 ASAP!
by Georg Koppen 10 Dec '23

10 Dec '23

Hello exit node operators! Today (2023-12-08) the Network Team has released a new Tor version, 0.4.8.10[1]. This update contains a fix to a remotely triggerable crash bug (TROVE-2023-007) affecting exit relays on the 0.4.8.x series. Please upgrade as soon as possible to maintain network stability and security if your relays are on that series. For those of you running their Tor relays using the Tor Debian repository, expect a new deb package to be available soon. Please note that this bug is specific to Tor exit relays on the 0.4.8.x series and does not impact other relays nor Tor clients or Tor powered apps (Tor Browser, Orbot, OnionShare). Thanks, Georg [1] https://forum.torproject.org/t/security-release-0-4-8-10/10536

3 2

Relay question
by Mulloch94 08 Dec '23

08 Dec '23

Greetings, I was directed to this relay subscription by the owner. I've recently started my own relay and everything has went smooth for the first few days. Then the relay mysteriously went offline for a period of 8-9 hours. Happened while I was sleeping I think, but any rate it came back on after I restarted the tor daemon and rebooted the server. I'm starting to think my firewall configurations might have been the culprit, even though I ran a very rudimentary setup. Basically just: -A INPUT -p tcp --dport <my SSH> -j ACCEPT -A INPUT -p tcp --dport 9050 -j ACCEPT -A INPUT -p tcp --dport 443 -j ACCEPT -A INPUT -p tcp --dport 80 -j ACCEPT -A INPUT -j DROP Default ACCEPT on OUTPUT My ORPort is on 443, so I don't see how this could be interfering. I noticed my server reboot got rid of all my rules, so I'm thinking that could've been the issue. If so, what other ports should I add? Do I even need a firewall for the relay? I don't do anything else with that server, so If it doesn't need a firewall to stay secure I won't use one. One more thing, I had a flag on my relay that said I needed to "update the descriptor." It went away after rebooting my server as well, could that been the issue? Sent with [Proton Mail](https://proton.me/) secure email.

3 2

Re: [tor-relays] Relay question
by denny.obreham＠a-n-o-n-y-m-e.net 08 Dec '23

08 Dec '23

For your firewall settings, you will find everything you need here: https://github.com/Enkidu-6/tor-ddos/ It is the common setting for most Tor operators. Although, I don't think it is the source of your problem and I wouldn't worry too much about it unless it happens repeatedly. The log in "/var/log/syslog" might give you some helpful hints. Denny On 12/07/2023 10:19 PM Mulloch94 via tor-relays <tor-relays(a)lists.torproject.org> wrote .. > Greetings, I was directed to this relay subscription by the owner. I've recently > started my own relay and everything has went smooth for the first few days. Then > the relay mysteriously went offline for a period of 8-9 hours. Happened while I > was sleeping I think, but any rate it came back on after I restarted the tor daemon > and rebooted the server. I'm starting to think my firewall configurations might > have been the culprit, even though I ran a very rudimentary setup. Basically just: > -A INPUT -p tcp --dport <my SSH> -j ACCEPT > -A INPUT -p tcp --dport 9050 -j ACCEPT > -A INPUT -p tcp --dport 443 -j ACCEPT > -A INPUT -p tcp --dport 80 -j ACCEPT > -A INPUT -j DROP > > Default ACCEPT on OUTPUT > > My ORPort is on 443, so I don't see how this could be interfering. I noticed my > server reboot got rid of all my rules, so I'm thinking that could've been the issue. > If so, what other ports should I add? Do I even need a firewall for the relay? > I don't do anything else with that server, so If it doesn't need a firewall to > stay secure I won't use one. One more thing, I had a flag on my relay that said > I needed to "update the descriptor." It went away after rebooting my server as > well, could that been the issue? > > Sent with [Proton Mail](https://proton.me/) secure email.

1 0

EFF's university Tor relay campaign
by Roger Dingledine 08 Dec '23

08 Dec '23

Hi folks! EFF has launched their advocacy campaign for getting more Tor relays running at universities: https://toruniversity.eff.org/ https://www.eff.org/deeplinks/2023/08/announcing-tor-university-challenge https://www.eff.org/press/releases/eff-launches-tor-university-challenge We're focusing on universities in particular, not just to get more capacity for the Tor network, but also to strengthen the connections between the Tor network and academia. Universities are great locations for Tor relays for education (Tor is part of every cybersecurity curriculum these days), for community (growing connections between students and research groups), and for research (helping the Tor network stay strong so people can use it for research): https://toruniversity.eff.org/administrators/ https://blog.torproject.org/tor-heart-pets-and-privacy-research-community/ Having more relays at universities is especially useful because it can help others to see that running a relay is a normal and straightforward thing to do. So: if you are at a university, or you know somebody who is and want to help them, please consider setting up relays there. It can be anything from an exit relay (the most useful to Tor users, but the most work in terms of local advocacy and relationship-building), to a non-exit relay (still very useful to Tor users, because we need more network diversity), to a non-NATed Snowflake bridge (currently used most by people in Iran to get around their censorship and reach the Tor network). We started the campaign with thirteen institutions that are already running relays and/or other public infrastructure pieces: Technical University Berlin (Germany) Boston University (US) University of Cambridge (England) Carnegie Melon University (US) University College London (England) Georgetown University (US) Johannes Kepler Universität Linz (Austria) Karlstad University (Sweden) KU Leuven (Belgium) University of Michigan (US) University of Minnesota (US) Massachusetts Institute of Technology (US) University of Waterloo (Canada) Hopefully this list will make you impressed / excited / jealous and you will want to get your university onto it. :) Later steps in the campaign will be to understand which universities have IT departments that understand and value Tor, and which ones try to block you from using Tor on their network or block Tor users from reaching their webservers. We are also imagining to do an OONI workshop to help people do "how well does Tor work on this network" tests. Here is the internal coordination/roadmap ticket if you want to follow along in detail: https://gitlab.torproject.org/tpo/community/relays/-/issues/67 Thanks! --Roger

2 3

Correction to Good Bad ISPs, UK
by code9n＠pm.me 02 Dec '23

02 Dec '23

Hi, This is probably the wrong place but here is a minor update to the Good / Bad ISPs page: http://xmrhfasfg5suueegrnc4gsgyi2tyclcy5oz7f5drnrodmdtob6t2ioyd.onion/relay… The company HostWorld in the UK does allow guard and middle relays but just refused me permission to change mine to an exit node. That's today, 2023-12-02. They're pretty good, I've had no problems, efficient customer support, unlimited bandwidth, but 'no' to exit relays. I don't know about bridges. ASN : AS42831. regards,

1 0

recommended way to run 0.4.7 on armhf?
by ilf 25 Nov '23

25 Nov '23

What's the recommended way to run 0.4.7 on armhf? > The package repository [deb.torproject.org] does not offer 32-bit ARM > architecture (armhf) images (yet). https://support.torproject.org/apt/tor-deb-repo/ Debian has 0.4.7 in bullseye-backports. But Raspbian doesn't have bullseye-backports: http://raspbian.raspberrypi.org/raspbian/dists/ -- ilf If you upload your address book to "the cloud", I don't want to be in it.

3 6

obfs4 bridge current setup is not entirely clear
by s7r 13 Nov '23

13 Nov '23

Hi, I ran into some new IP space and I decided to change a cluster of obfs4 bridges that are more than 4 year old. When I set them up I don't remember spending so much time. So, Debian latest and Tor latest from deb.torproject.org nightly. GoLang from the official website (as it's the latest version) and obfs4proxy cloned from its default git repository. 1. The page at https://community.torproject.org/relay/setup/bridge/debian-ubuntu/ needs a small revision. This page must be changed, for Debian it doesn't work simply $ edit tor@.service tor(a)default.service , change to NoNewPrivileges=no, save and quit. For me it only worked by editing /lib/systemd/system/tor@.service and /lib/systemd/system/tor(a)default.service with NoNewPrivileges=no and then: $ sudo systemctl daemon-reload. Setcap command is ok but it also need to mention to install the package in Debian libcap2-bin as well as an additional step: Under Debian, if obfs4proxy is installed in a different place, for example like in its git documentation /usr/local/bin/obfs4proxy then you also need to edit this file: /etc/apparmor.d/abstractions/tor and add one line (or change the default obfs4proxy line to): /usr/local/bin/obfs4proxy Pix, Substitute path if different and then: $ sudo systemctl restart apparmor. ------------------------------------------------ 2. It was recommended on the mail list that obfs4 bridges should not open their ORPorts publicly to prevent scanning the entire 1-65536 port range and determine it's a Tor bridge. OK. But if you try: ORPort 127.0.0.1:auto ORPort [::1]:auto AssumeReachable 1 # needed to skip ORPort reachability test Tor will start but it will constantly complain in the log with: [warn] The IPv4 ORPort address 127.0.0.1 does not match the descriptor address REAL_IPv4_ADDRESS. If you have a static public IPv4 address, use 'Address <IPv4>' and 'OutboundBindAddress <IPv4>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'. [warn] The IPv6 ORPort address ::1 does not match the descriptor address REAL_IPv6_ADDRESS. If you have a static public IPv4 address, use 'Address <IPv6>' and 'OutboundBindAddress <IPv6>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'. I guess it's OK to continue to run it even with this as I do understand the log messages and it's the desired effect, but isn't it confusing for less experienced users? They might think something is wrong when it is not. The recommended way is to add a simple logic to skip that check, because we can't remove it, it's vital necessary for relays (not bridges) behind NAT or dynDNS or whatever. So if BridgeRelay 1 is set and $some_transport enabled, ignore the ORPort and descriptor check / log. and instead check the pluggable transport if port open and listening. Or even better, code a pluggable transport port reachability test before building and uploading the descriptor, by cloning the code that does this for ORPorts to the pluggable transport ports. This would need a proposal that covers all use cases. 3. ServerTransportListenAddr can be used just once and it's difficult for dual-stack which is now the vast majority. It's known for many years that each pluggable transport supports just one ServerTransportListenAddr line, the second one is simply ignored. Tickets for this exist. So what is the best way to for an user to open both IPv4 and IPv6 pluggable transport ports? In Debian I have achieved it by using as wildcard ServerTransportListenAddr [::]:80 since the wildcard [::] under Debian binds to all IPv4 and IPv6 addresses on all interfaces, but this might not be the same for all operating systems. Also, how does BridgeDB determine in case wildcard [::] is used if the pluggable transport is IPv4, IPv6 or both? Which one is used when BridgeDB sends this bridge to clients?

3 4

Relay no longer acting as a gaurd node?
by Jonathan Proulx 12 Nov '23

12 Nov '23

Hi All, A little while ago one of my relays switched from usually acting as a guard node to never acting as a guard node: https://metrics.torproject.org/rs.html#details/9715C81BA8C5B0C698882035F75C… Doesn't matter to me if it's a guard or not jsut want to understand what's changed and if it's a problem. Do I have a misconfiguration? -Jon

6 5

"Failed to find node for hop #1 of our path"
by William Denton 12 Nov '23

12 Nov '23

Lately my relay hasn't been seeing much traffic, which I didn't notice for a while, but now I'm turning my attention to it. I just updated to 0.4.8.9 and see these notices (with some lines cut out): [all the startup stuff looks normal, ending with success] Nov 09 13:07:31.000 [notice] External address seen and suggested by a directory authority: 24.212.137.85 Nov 09 13:08:29.000 [notice] Self-testing indicates your ORPort 24.212.137.85:9001 is reachable from the outside. Excellent. Publishing server descriptor. Nov 09 13:10:39.000 [notice] Performing bandwidth self-test...done. [but then] Nov 09 13:36:42.000 [notice] Tor has not observed any network activity for the past 521 seconds. Disabling circuit build timeout recording. Nov 09 13:38:03.000 [notice] Failed to find node for hop #1 of our path. Discarding this circuit. Nov 09 13:38:03.000 [notice] Our circuit 0 (id: 151) died due to an invalid selected path, purpose Hidden service: Pre-built vanguard circuit. This may be a torrc configuration issue, or a bug. Nov 09 13:39:24.000 [notice] Failed to find node for hop #1 of our path. Discarding this circuit. Nov 09 13:40:10.000 [notice] Failed to find node for hop #1 of our path. Discarding this circuit. [later] Nov 09 14:01:27.000 [notice] Failed to find node for hop #1 of our path. Discarding this circuit. Nov 09 14:01:34.000 [notice] Tor now sees network activity. Restoring circuit build timeout recording. Network was down for 2013 seconds during 43 circuit attempts. Nov 09 14:02:35.000 [notice] No circuits are opened. Relaxed timeout for circuit 2627 (a Measuring circuit timeout 3-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway. Nov 09 14:02:44.000 [notice] Tor has not observed any network activity for the past 66 seconds. Disabling circuit build timeout recording. Nov 09 14:04:03.000 [notice] Failed to find node for hop #1 of our path. Discarding this circuit. Nov 09 14:06:24.000 [notice] Failed to find node for hop #1 of our path. Discarding this circuit. There are hundreds of those notices about failing to find a node for hop #1. (I don't know why it complains about the network being down to 2013 seconds (over half an hour), because I didn't notice anything, but there were scores of the same warnings before that.) What would cause this, or what could I do to identify the problem? Bill Denton -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 419.18 ppm (Mauna Loa Observatory, 2023-11-07)

2 1