- tor-relays - lists.torproject.org

Relay "unmeasured" after update to 0.4.7.8
by Martin 27 Jun '22

27 Jun '22

Hi all! After updatering to the latest version, my relay consensus went down to 20 and was marked unmeasured. However it still serves a couple of thousand connections (capped at 10 MB/s) and all flags are still there, but when I try to use it to build a circuit manually it won't let me... Cheers

2 1

Metrics shows my relay down. But it's not.
by Eddie 25 Jun '22

25 Jun '22

The metrics is showing one of my relays (40D13096BBD11AF198CE61DEE4EAECCE5472F2E7) as down for around the last 3 hours. Logging in to it, I see everything running normally. This server has also lost a bunch of flags for no apparent reason, so I'm not sure if they're connected. Cheers.

2 1

FreeBSD 13.1: clock_gettime(CLOCK_MONOTONIC_FAST) ~ 50 % performance gain
by Andreas Kempe 22 Jun '22

22 Jun '22

Hello everyone, I was doing some profiling on my two relays running on FreeBSD 13.1 and noticed that they were spending a lot of time in clock_gettime() which prompted me to have a look at the implementation. Time implementation =================== The time implementation is abstracted in src/lib/time/compat_time.c where different mechanisms are used for different operating systems. On Linux CLOCK_MONOTONIC_COARSE is a clock that gives worse precision than CLOCK_MONOTONIC, but is faster and the abstraction layer checks for its presense and provides more performat less precise time where applicable. On FreeBSD, there is also a fast monotonic time source available called CLOCK_MONOTONIC_FAST. In the header file src/lib/time/compat_time.h, a comment references this clock, but it is not used. I thought it might be worth a shot seeing what difference it would make if I enable the use of CLOCK_MONOTONIC_FAST on FreeBSD and on the VM where I run my two FreeBSD relays, the difference was stunning. I made did a quick patch simply replacing CLOCK_MONOTONIC_COARSE with CLOCK_MONOTONIC_FAST, see patches attached, compiled and tested. Tracing system calls to make sure the correct call was being used, which it was. Results ======= This lead to reducing the CPU usage of the patched relay by about 50 % compared to the unpatched relay. I was a bit shocked so I wrote a small benchmark program and ran it on my VM giving the following results: CLOCK_MONOTONIC: 4.776675 s CLOCK_MONOTONIC_FAST: 0.260002 s Showing that on my VM the performance of CLOCK_MONOTONIC_FAST is about 20 times better than CLOCK_MONOTONIC. I have tested on a few different systems and I think that the performance increase of CLOCK_MONOTONIC_FAST is thanks to commit 60b0ad10dd0fc7ff6892ecc7ba3458482fcc064c - "vdso: lower precision of vdso implementation of CLOCK_MONOTONIC_FAST and CLOCK_UPTIME_FAST" that was cherry-picked to 13.1. Try it yourself and report your results ======================================= If you want to benchmark your server to see whether switching clock could benefit you, you can compile and run my attached test program by doing user>clang -o bench.c -o bench user>./bench In case the program terminates too quickly or slowly for your liking, adjust const unsigned long iterations = 1000000; up or down to change the execution time. My supplied patches appear to work fine on my system, but aren't really upstream appropriate since a solution that works for both FreeBSD and Linux is needed. If you want to test them and you're building Tor from the ports tree, drop them in /usr/ports/security/tor/files and build and install. I'm very interested in seeing some performance data from other people to see whether I think it worth either pestering some Tor devs to have a look at this or putting in some effort myself to write an upstreamable patch. Thank you for reading! Cordially, Andreas Kempe

3 4

From [tor-announce] Tor stable release 0.4.7.8 - Security Fix
by Felix 20 Jun '22

20 Jun '22

> We have released tor 0.4.7.8 earlier today, a new stable version for > the 0.4.7.x series containing an important High severity security > fix. The affected tor are only those of the 0.4.7.x series as in from > tor-0.4.7.1-alpha to tor-0.4.7.7. Jun 18 10:08:46.000 [notice] This version of Tor (0.4.7.8) is newer than any recommended version, according to the directory authorities. -- Cheers Felix

2 1

EXPKEYSIG when running 'apt update'
by Imre Jonk 17 Jun '22

17 Jun '22

Hi tor-relays, I'm getting this error when running 'apt update': Err:4 https://deb.torproject.org/torproject.org bullseye InRelease The following signatures were invalid: EXPKEYSIG 74A941BA219EC810 deb.torproject.org archive signing key The signing key in /etc/apt/trusted.gpg.d/deb.torproject.org-keyring.gpg does not appear to be expired, so I guess some repository metadata signature has expired. Does anyone else encounter this issue? Thanks, Imre

4 4

Identifying a relay
by Eddie 16 Jun '22

16 Jun '22

Have a question about how a server I connect to can tell I am running a guard/middle relay. All I can think of is that they check the published list of tor nodes against the IP. Or (maybe, but unlikely) portscan the IP and probe any open ports to determine the service. Are there any other methods that can be used. Background: The corp my wife works for blocked our IP. The excuse they gave was that it was due to a change made by a vendor they use to identify malicious IP addresses. I have been running the relay for almost 5 years without any previous flagging. They also state that running a middle relay is not in violation of any policy, but the vendor mis-identified our relay as an exit, hence blocking it. After changing the IP, the new IP was also blocked in less than 24 hours. My feeling is that the vendor is now just using the full list of tor nodes and indiscriminately blocking everything, despite what the corp security folks say. I'm looking for some sort of validation I can use to counter their claims.

5 5

(No Subject)
by Admin Platinum Host 14 Jun '22

14 Jun '22

Hi there, I currently own a Tor Relay that has been running since 2022-05-24. A day ago it restarted, which was a bit strange. Recently I found that the Relay has changed to a Guard Relay, which I am pleased about. I was wondering why the restart occurred as the VPS Server has been online since the first start. The Relay is called UKLondonRelay1 with the IP address 80.64.218.62. https://metrics.torproject.org/rs.html#details/B1B1CAD0A73EC5148B06A0A0E819… Any help on this matter would be appreciated. Kind regards, Leon The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.

1 0

[Workshop] Sysadmin 101 for (new) relay operators - June 4th @ 1900 UTC
by gus 14 Jun '22

14 Jun '22

Join us June 4th at 1900 UTC for new and prospective Tor relay and bridge operators on the basic "sysadmin foo" required to contribute to the network! ## Sysadmin 101 for new relay operators So you want to contribute to the open-source Tor network by running a relay or maybe a bridge? The Tor network is the most important tool for evading surveillance and bypassing internet censorship. And Tor relays and bridges are vital to the health and integrity of the Tor network. Millions of users rely on relays and bridges to stay safe, and how you configure and maintain that relay or bridge is critical. Volunteers aren't a nice enhancement. They are a core feature. Running a relay or a bridge raises frequent questions: * Should I run a relay or a bridge? * Should I run a relay or a bridge from a residential/home internet connection? * Which operating system should I run for my Tor node (hint: the one you are most comfortable with securing and maintaining) * More generally, what does it take to keep that relay or bridge operating safely, but both you and Tor users? This workshop will start with a presentation approaching some of the core issues that arise when running a Tor node. The session will move into an "ask me anything" discussion to approach other common and less common questions. The 90-minute event will be geared towards current and prospective Tor bridge and relay operators, particularly those relatively new to running public internet services. Seasoned Linux and BSD Tor operators will be attending the event ready to address the discussion. ## How to join the workshop The workshop is entirely free, and participants need to fill out this registration form. The event will take place on BigBlueButton, an online video conference platform, on June 4th at 1900 - 2030 UTC. You can register here: https://nc.torproject.net/apps/forms/cDLPxryHJcP5kMeW ## Facilitators The workshop will be facilitated by: * George (@gman999) - Tor *BSD Diversity Project member, Serge bridge directory authority maintainer, long-time relay operator and a wide variety of other contributions. * Kushal Das (@kushal) - RPM Tor maintainer and member of the Tor Community team. -- The Tor Project Community Team Lead

2 3

My current node setup
by Nyasaki Server 07 Jun '22

07 Jun '22

Hi to all new ppl that may have joined after the sysadmin101 workshop. I decided to share my setup here in case any newbies are interested and maybe somebody who is doing this for a while longer than me sees any flaws in my setup. Feedback is always welcome! I was tired of using the debian testing for running my node and decided to redo my node with arch because of the fast package updates and rolling release model. Currently my setup consists of 3 servers: Exit-Node: Archlinux with tor, unbound and prometheus running, prometheus is a nice metric collection service that nicely collects the statics that tor exposes. It's a VPS hosted at Terrahost in Norway for 20$ / month with 2 vCPU’s and 4GB Memory. Unbound only resolves requests from localhost, due to a high percentage of DNS timeouts in the past I decided to use this just as backup and resolve everything else via the dedicated DNS server. Tor is set up to expose the metrics to localhost, where prometheus is running. The actual prometheus metrics port is just allowed for 1 IP, thats the one my Dashboard server has. The firewall is set up to allow every port that's listed in my torrc, my non-default ssh port and the IP of my dashboard for the metrics port. DNS: Ubuntu 22.04 LTS (due to oracle clouds small selection of images) with unbound as DNS and prometheus. Hosted at Oracle Cloud via the free tier with 1 vCPU and 1GB Memory. The firewall is open for DNS requests from my node ip, metrics requests from my dashboard IP and non-default ssh port. Dashboard: Ubuntu 22.04 LTS with unbound as DNS and prometheus. Hosted at Oracle Cloud via the free tier with 1 vCPU and 1GB Memory. There's a Grafana dashboard and the Prometheus server running. Again all ports blocked but ssh and http/https are open Image of the Dashboard https://imgur.com/a/fYpRD8O My Node https://metrics.torproject.org/rs.html#details/017342E197B8C575A5C5301CD008… My GPG Key https://keyserver.ubuntu.com/pks/lookup?search=nyasaki.srv%40gmail.com&fing…

3 2

New OrNetStats Section: Largest Bridge Operators
by nusenu 07 Jun '22

07 Jun '22

Hi, OrNetStats got a new section today showing the largest bridge operators by advertised bandwidth grouped by ContactInfo: https://nusenu.github.io/OrNetStats/#bridge-operators-grouped-by-contactinfo This is possible because the Torproject started to publish bridge ContactInfos. The listing only includes operators with at least 50 Mbit/s aggregated advertised bandwidth. AROI support for bridges You can also protect your bridge ContactInfo against spoofing now. The same fields as for relays apply. If you have setup your AROI [1] on your relays already you can simply copy the ContactInfo to your bridges and publish the list of hashed bridge fingerprints under this URL: https://-your-hostname-/.well-known/tor-relay/hashed-bridge-rsa-fingerprint.txt After successful validation your bridges will be added to your operator level pages on OrNetStats. OrNetRadar will also be extended to support bridges. kind regards, nusenu [1] https://nusenu.github.io/OrNetStats/#authenticated-relay-operator-ids -- https://nusenu.github.io

3 3