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

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 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

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

Bridge with iat-mode=2 very slow
by Split 28 Sep '23

28 Sep '23

Hello everyone! I run the obfs4 bridge, in the parameters I specify to use iat-modr=2. As a result, the bridge is VERY, VERY SLOW. Connection speed is on average 100 kb/sec. When I remove the iat-mode=2 parameter, the speed becomes 8-10 times higher. I checked the processor load, it is at 3%, the problem is unlikely to be with the processor, the RAM load is at 20%. I can't figure out if this is expected behavior or if the speed drop is too significant. Please tell me, is this the normal maximum speed of the bridge with iat-mode=2 or can it be increased somehow?

3 2

Tor Weather : Node-Flag [Guard] Alert
by denny.obreham＠a-n-o-n-y-m-e.net 27 Sep '23

27 Sep '23

I received the following message from Tor Weather. According to Tor Metrics, this exit relay still has no Guard flag. Another - slightly more recent - exit relay (25FC41154DCB2CAE3ABD74A8DFCD5B90D2CFFD57) is on the same server and IP, and still has the Guard flag (although with 0% guard probability). Should I do something with this info? Denny On 09/26/2023 06:31 PM weather(a)torproject.org wrote .. > > > Hi, > > We have detected that the node - 3B85067588C3F017D5CCF7D8F65B5881B7D4C97C associated > with your subscription has lost the Guard flag > for more than 1hr(s). This may impact the performance of your service. > > Thank You!

2 1

Grafana dashboards
by Toralf Förster 16 Sep '23

16 Sep '23

Yesterday I stumbled together 2-3 dashboards [1] for Tor relay(s), Tor Snowflake(s) and the DDoS solution [2]. Feedback is welcome. [1] https://github.com/toralf/torutils/tree/main/dashboards [2] https://github.com/toralf/torutils/tree/main -- Toralf

1 0

Metrics
by BridgeOverStyx 08 Sep '23

08 Sep '23

My bridge styxVortex is up and running. I know this because the Nyx monitor shows activity. However, a search of metrics.torproject.org shows it down. It has been in this state for at least a month. Do you have any suggestions of what could be the possible cause of this? I am using pfblockerng on my network, but the machine that is running Tor bridge is not filtered by it. I do have a couple of TOR feed enabled in pfblockerng but only incoming traffic is filtered. I have no idea how the bridge stats are passed to metrics.torproject.org so it is very challenging for me to tamp down on the cause. Any suggestion, at this point, will be helpful. Sent with [Proton Mail](https://proton.me/) secure email.

6 9

Quick bugfix sharing regarding obfs4 malfunctioning
by telekobold 07 Sep '23

07 Sep '23

Hi, I just want to share some quick bugfix with you (sorry if this is obvious to you or has been written somewhere else). Suddenly, I got the following error messages on my two bridges running on Debian 11 appearing in the logs (in /var/log/tor/notices.log and in the nyx output) every second until a restart: <timestamp> [warn] Managed proxy "/usr/bin/obfs4proxy" process terminated with status code 65280 <timestamp> [warn] Server managed proxy encountered a method error. (obfs4 listen tcp 0.0.0.0:443: bind: permission denied) <timestamp> [warn] Managed proxy '/usr/bin/obfs4proxy' was spawned successfully, but it didn't launch any pluggable transport listeners! When restarting the corresponding bridge, in the startup process the second and the third of the above warning messages again appeared in the logs. So obfs4 was suddenly not usable any more. Port 443 is not blocked in the bridge's firewalls. A bit research reveled that apparently, an automatic update set the systemd setting "NoNewPrivileges=no" in /lib/systemd/system/tor(a)default.service and tor@.service [1] back to yes, which caused the above issue. After setting it back and restarting, everything works fine now and instead of the warning messages mentioned above, the following message appears in the log again: <timestamp> [notice] Registered server transport 'obfs4' at '[::]:443' (Several places recommend to set the obfs4 port to 443 to get around restrictive firewalls, so I didn't want to set it to something else). Kind regards telekobold [1] http://xmrhfasfg5suueegrnc4gsgyi2tyclcy5oz7f5drnrodmdtob6t2ioyd.onion/relay…

3 2

(Last call) Bridges running obsolete Tor version (0.4.5.x) to be removed soon
by gus 05 Sep '23

05 Sep '23

Hi bridge operators, Serge, the Bridge Authority is about to update their Tor version to 0.4.8.5 and it will reject bridges running the Tor version 0.4.5.x. Please upgrade your bridge if you're running an outdated version (0.4.5.x) ASAP. List of outdated bridges: https://metrics.torproject.org/rs.html#search/type:bridge%20version:0.4.5%20 Thanks for helping censored users to bypass censorship! cheers, Gus -- The Tor Project Community Team Lead

2 1