November 2023 - tor-relays - lists.torproject.org

Attempting to create a relay with Orbot
by blueapple128 20 Jun '25

20 Jun '25

Hi, I am trying to use Orbot's "Enable your device to be a non-exit relay" option, but (after waiting enough hours) the relay's nickname fails to show up in Tor Metrics' Relay Search. How can I begin to debug this?

2 2

Running a high-performance pluggable transports Tor bridge (FOCI 2023 short paper)
by David Fifield 11 Dec '23

11 Dec '23

Linus Nordberg and I wrote a short paper that was presented at FOCI 2023. The topic is how to use all the available CPU capacity of a server running a Tor relay. This is how the Snowflake bridges are set up. It might also be useful for anyone running a relay that is bottleneck on the CPU. If you have ever run multiple relays on one IP address for better scaling (if you are one of the relay operators affected by the recent AuthDirMaxServersPerAddr change), you might want to experiment with this setup. The difference is that all the instances of Tor have the same relay fingerprint, so they operate like one big relay instead of many small relays. https://www.bamsoftware.com/papers/pt-bridge-hiperf/ > The pluggable transports model in Tor separates the concerns of > anonymity and circumvention by running circumvention code in a > separate process, which exchanges information with the main Tor > process over local interprocess communication. This model leads to > problems with scaling, especially for transports, like meek and > Snowflake, whose blocking resistance does not rely on there being > numerous, independently administered bridges, but which rather forward > all traffic to one or a few centralized bridges. We identify what > bottlenecks arise as a bridge scales from 500 to 10,000 simultaneous > users, and then from 10,000 to 50,000, and show ways of overcoming > them, based on our experience running a Snowflake bridge. The key idea > is running multiple Tor processes in parallel on the bridge host, with > externally synchronized identity keys.

3 4

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

07 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

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 11 Nov '23

11 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

Re: [tor-relays] Relay no longer acting as a gaurd node?
by denny.obreham＠a-n-o-n-y-m-e.net 11 Nov '23

11 Nov '23

On 11/9/23 16:03, Jonathan Proulx wrote: > 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? I had a similar event about a month ago and everything came back to normal on its own. I found that the following answer to my question on this mailing list was very helpful: https://lists.torproject.org/pipermail/tor-relays/2023-September/021334.html

1 0

Money for relay operators and email addresses
by code9n＠pm.me 04 Nov '23

04 Nov '23

tl;dr: Paying relay operators - yes, once it's decided how to share out the money. Requiring valid email addresses - yes. imo s. It goes against the purely altruistic bit of me to say this but I definitely see the advantage of paying relay operators. I run one pretty powerful relay on a commercial vps, costs me around $200 a year. I'd run more but the money starts to pile up . . . so if I got significant enough recompense I would run more - good for Tor. Also, has it been decided exactly how the money will be shared out? If it's on the number or relays you operate that will incentivize many slow, weak relays at the expense of a few fast, good ones - bad for Tor. If it's on advertised bandwidth, is that hack-able? It changes over time, do you take the average? The figure on accounting day? Do you go on the bytes per second? Terabytes per month? The consensus weight? Do you pay more for exit nodes as they're more 'useful', more, valuable to the network as a whole? How about guards as opposed to middle, or bridges, snowflakes, etc.? Do you reward / penalize operators for / not keeping their relays up to date, etc.? Also paying for nodes could make it more viable for three letter agencies, etc. to run more relays, but I doubt it's about money for them as much as it is for us. Or for relay abusers like those that were stealing crypto wallet creds. On the whole it's probably better for tor to pay than not to, imo, (from the relay operators donations pot). Or someone could run a DoS attack by earning a significant proportion of all the money in the pot then shutting down their relays all at once. Especially if the network grows to rely on the donations money. All of this 'sharing out donations money' thing is moot if the amount of money we'd each receive is trivial compared to the cost of running relays . . . xxxxxxxxxxxxxxxxxxxx On the subject of requiring valid email addresses, I can't see any good reason not to do so. It would be quite difficult to run a relay completely anonymously, especially if you have to pay for anything. If you can achieve that, an email address that's not link-able to you shouldn't be beyond your ability. And there are potentially occasions when Tor might want to contact you discreetly. If you're doing something foolish or wrong do you really want it pointed out in a general announcement? My only reservation would be regarding receiving spam but as, I think it was @Boldsuck, said, that's not much of an issue in practice.

1 0

Please upgrade to new Tor release 0.4.7.16 or 0.4.8.8 ASAP!
by gus 03 Nov '23

03 Nov '23

Dear relay operators, Today (2023-11-03) the Network Team has released new Tor versions 0.4.7.16 and 0.4.8.8[1]. These updates contains a fix to a remote crash bug (TROVE 2023 004). It is highly recommended that all relay operators upgrade to the new versions as soon as possible to maintain the network stability and security. For those running their Tor relay using the Tor Debian repository, expect the new deb package to be available soon. The patches prevents the issue from causing a crash in Tor. However, it will make Tor more noisy when the bug is triggered, including logging information about the remote peer that is the source or destination of the circuit in the path. Such information is important for our developers to diagnose the specific invariant within Tor's TLS logic that does not hold. Eventually, a new version of Tor will need to be released in the future that will remove the verbose logging of this issue. Please note that this bug is specific to Tor relays and does not impact Tor clients or Tor powered apps (Tor Browser, Orbot, OnionShare). Thank you, Gus [1] https://forum.torproject.org/t/security-release-0-4-7-16-and-0-4-8-8/10064 -- The Tor Project Community Team Lead

1 0