- tor-relays - lists.torproject.org

Bridges and Hs_vanguards
by dmz21 12 Jul '22

12 Jul '22

Dear readers, During the last week the bytes/second of my bridge dropped to 20% of its common usage over the past months, while the average number of connected clients stayed the same (according to metrics.torproject.org) I'm also seeing a dozen circuit connections with purpose Hs_vanguards in nyx recently, which are not familiar to me. Under-utilization of my bridge is not a problem to me, but maybe someone can tell me whether the two are related? Maybe it's an issue at my end or my hoster or maybe a generic issue of the tor network currently? Or maybe it's all normal? Thanks and best regards

1 0

We're trying out guard-n-primary-guards-to-use=2
by Roger Dingledine 11 Jul '22

11 Jul '22

Hi folks, As part of the hackweek projects ( https://gitlab.torproject.org/tpo/community/hackweek/ ), some of us are thinking about simple tweaks we can do to tune the network to better handle this month's traffic overload. The long term answer is to try out proposal 327: https://gitweb.torproject.org/torspec.git/tree/proposals/327-pow-over-intro… because we think a lot of the overload has to do with people sending way too many intro cells to some onion services, and giving the onion services ways to defend themselves is the only real answer. But while we're thinking about implementing that proposal, one of our earlier steps is to set the guard-n-primary-guards-to-use consensus parameter from 1 to 2. Now that it's taken effect (you can watch the votes at https://consensus-health.torproject.org/#consensusparams ), this change means that clients will now choose between two guard relays by default (rather than just one) when building circuits. This is potentially a big deal, since it puts us into a different point in the performance vs safety tradeoff space. Here is some reading for why we originally moved down to 1 guard by default: https://blog.torproject.org/improving-tors-anonymity-changing-guard-paramet… https://www-users.cse.umn.edu/~hoppernj/single_guard.pdf But on the theory that some guards are way overloaded right now and some aren't, giving clients two bites at the apple might make a dramatic improvement in terms of reliable and consistent performance. There is also some argument in favor of using two guards anyway. One reason (explained more in proposal 291) is that there are already some edge cases where clients use their second guard. And also, in the glorious future, we will want to be using multiple guards because we have switched to the multi-path Conflux design (proposal 329) -- though we're not there yet. So: I am giving you all here some early warning, in case you see anything odd on the network when we make this change. Let us know if you do. :) --Roger

4 5

Is ExoneraTor still alive?
by Christian Pietsch 07 Jul '22

07 Jul '22

Dear all, ExoneraTor is/was useful for showing law enforcement authorities that a given IP address acted as a Tor exit relay at a given day. Unfortunately, ExoneraTor seems to be offline. This page does not work at all, returning an HTTP 503 error immediately: https://exonerator.torproject.org/ This page returns the following error whenever I submit an IP address: https://metrics.torproject.org/exonerator.html | Server problem | | Unable to connect to the database. Please try again later. If this problem persists, please let us know! Can it be revived? Can I help? Cheers, Christian -- Christian Pietsch volunteering for Digitalcourage e.V. https://digitalcourage.de/ – Swarm support: https://digitalcourage.de/swarm-support – German BigBrotherAwards: https://bigbrotherawards.de/

2 1

[Event] Tor relay operator meetup - June 25th @ 1900 UTC
by gus 27 Jun '22

27 Jun '22

Hello, The next Tor relay operator meetup will happen on Saturday, June 25 @ 1900 UTC. Where: BigBlueButton - https://tor.meet.coop/gus-og0-x74-dzn No need for a registration or anything else, just use the room-link above. We will open the room 10 minutes before so you can test your mic setup. Everyone is free to bring up additional questions or topics at the meeting itself. Please share with your friends, social media and other mailing lists! cheers, Gus -- The Tor Project Community Team Lead

1 2

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