- tor-relays - lists.torproject.org

Read/written bytes on a relay differ
by Richie 23 Sep '24

23 Sep '24

Hi everyone, nothing of real concern, but out of curiosity: since some years now i use overhead traffic on my ISP for Tor, with a small home relay burning some 3 to 4 MB/Sec. Usual middle relay plus V2Dir (and HSdir some days after last reboot). Since some weeks now, the read/written bytes differ quite significantly, and i never experieced sth like that for a relevant timespan before. Is this a sign of more "reading directory services" on the relay? (maybe short reqests and verbose replys), some new kind of attack, whatever? direct metrics-Link via https://metrics.torproject.org/rs.html#details/11FC7D9C7D8DF74326B90EC71C10… and screenie attached. Again, no big issue, just curiosity. And if its some kind of bug, i'd be happy to hand over more info. thx to everyone maintaining and running this stuff, Richie

2 1

[Important] Update on an upcoming German broadcasting story about Tor/Onion Services
by isabela fernandes 19 Sep '24

19 Sep '24

Hi Tor, I am reaching out to inform you of an upcoming news story concerning a potential deanonymization attack on Onion Services. What is happening? On September 9, 2024, The Tor Project received a press inquiry from Norddeutscher Rundfunk (NDR, part of ARD, a German public broadcaster) with a request for comment to their upcoming reporting of "investigative measures by German and international law enforcement agencies in the Tor network, in particular the localisation and deanonymisation of onion services." We complied with the outlet's deadline of September 12th and answered a series of questions. The reporter claims to have "evidence that shows that in several cases German law enforcement authorities were able to locate the Tor entry node of onion services and thus successfully deanonymise Tor users. V2 and V3 onion addresses were affected at least between Q3/2019 and Q2/2021." The reporter further claims that "law enforcement agencies used so-called timing analyses and broad and long-term monitoring of Tor nodes in data centres." As of today, The Tor Project has not been granted access to supporting documents, and has not been able to independently verify if this claim is true, if the attack took place, how it was carried out, and who was involved. In the absence of facts, it is hard for us to issue any official guidance or responsible disclosures to the Tor community, relay operators, and users at this time. We are calling for more information from you. If you have any information that can help us learn more about this alleged attack, please email security(a)torproject.org. If you want to encrypt your mail, you can get the OpenPGP public key for this address from keys.openpgp.org. Fingerprint: 835B 4E04 F6F7 4211 04C4 751A 3EF9 EF99 6604 DE41 Your assistance will help all of us take the necessary steps and precautions to keep Onion Services safe for the millions of users that rely on the protections Tor provides. Are Tor users safe? Tor users can continue to use Tor Browser to access the web securely and anonymously. Nothing that the Tor Project has learned about this incident suggests that Tor Browser was attacked or exploited. We encourage Tor Browser users and relay operators to keep software versions up to date. The reporter's questions focus on the use of onion services and .onion addresses. Which leads us to assume that the alleged attack was targeting a specific .onion site. We will continue to share updates on this email as this situation evolves. Thank you! Isabela

9 10

[warn] Error relaying cell across rendezvous; closing circuits
by Logforme 16 Sep '24

16 Sep '24

I run the non-exit relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3 Today I noticed two [warn] lines in the Tor log file that I have not seen before: [warn] Error relaying cell across rendezvous; closing circuits [warn] circuit_mark_for_close_(): Bug: Duplicate call to circuit_mark_for_close at ../src/core/or/command.c:577 (first at ../src/core/or/relay.c:343) (on Tor 0.4.8.12 ) I assume this is more of a FYI for the developers than for me as an operator. I'll keep an eye out to see if they appear more times.

1 0

Re: [tor-relays] tor-relays Digest, Vol 164, Issue 10
by Account Etheron 14 Sep '24

14 Sep '24

Your node has low Consensus Weight. Also your node is not marked as "Fast" Normal that happens between a week. Also advertised traffic is very low. https://metrics.torproject.org/rs.html#details/A00E3AAF5A24DC69740FA7A3A1C4… Low Consensus Weight (like 11) could be due to several factors: 1. *Low Bandwidth*: If your node has a limited bandwidth or is not properly configured to advertise its available bandwidth, it might get a lower weight. 2. *Unstable or Intermittent Availability*: Nodes that are frequently going offline or showing unstable behavior will have a lower consensus weight. 3. *Geolocation or Restrictions*: Certain regions or configurations may cause your node to have reduced visibility or reliability in the eyes of Tor's directory authorities. To improve the consensus weight of a Tor node: - Ensure *high uptime* and a reliable internet connection. - Advertise higher *bandwidth* if available. - Make sure your node is properly configured with the *right ports and keys*. Regards. On Sat, Sep 14, 2024 at 2:00 PM <tor-relays-request(a)lists.torproject.org> wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Relay suddenly pushing very little traffic (Zachary) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 13 Sep 2024 12:23:52 +0000 > From: Zachary <secure-communications-zachary(a)protonmail.ch> > To: "tor-relays(a)lists.torproject.org" > <tor-relays(a)lists.torproject.org> > Subject: [tor-relays] Relay suddenly pushing very little traffic > Message-ID: > > <jOspt2hq9xeYGyZ8fsFy_qO_4d_TtxrOmCJxPIPzAyF948JHR0_2saC8hGGKPkleMwcLMFcXbPVucHhRfnXLZfBjn_Wx2VYGC46r1wpqnaI=@ > protonmail.ch> > > Content-Type: text/plain; charset="utf-8" > > Hello all, > > I am the operator of relay AS11796EntryMiddle. > > This is a strategically placed relay on a 106.4 mbps internet connection > with no fluctuations in bandwidth available to it. The relay has very good > peering to major backbone providers such as Arelion which allows many > people to access it with minimal network hops, which is why I host it in > that ISP?s network. > > Over the past six months, I typically saw traffic ranging between 15 and > 70mbps. Now suddenly the relay seemingly can?t efficiently process traffic, > the advertised bandwidth has tanked, and it?s pushing virtually no data. > > I am running Tor 4.8.12 installed from the official Tor repositories in > Ubuntu 22.04 with OR port 9001. The entire network is an EdgeRouter plugged > into WAN and then a firewall rule letting traffic hit the host for Tor. The > relay is indeed working, but everyday it seems that less and less traffic > is getting through (this is very evident on Tor metrics.) TCP connections > are not exhausted so I?m pretty confused what?s going on. > > Any thoughts? Not trying to waste anyone?s time just don?t want this relay > to go to waste. > > Thanks, > Zachary >

1 0

Relay suddenly pushing very little traffic
by Zachary 13 Sep '24

13 Sep '24

Hello all, I am the operator of relay AS11796EntryMiddle. This is a strategically placed relay on a 106.4 mbps internet connection with no fluctuations in bandwidth available to it. The relay has very good peering to major backbone providers such as Arelion which allows many people to access it with minimal network hops, which is why I host it in that ISP’s network. Over the past six months, I typically saw traffic ranging between 15 and 70mbps. Now suddenly the relay seemingly can’t efficiently process traffic, the advertised bandwidth has tanked, and it’s pushing virtually no data. I am running Tor 4.8.12 installed from the official Tor repositories in Ubuntu 22.04 with OR port 9001. The entire network is an EdgeRouter plugged into WAN and then a firewall rule letting traffic hit the host for Tor. The relay is indeed working, but everyday it seems that less and less traffic is getting through (this is very evident on Tor metrics.) TCP connections are not exhausted so I’m pretty confused what’s going on. Any thoughts? Not trying to waste anyone’s time just don’t want this relay to go to waste. Thanks, Zachary

1 0

Supporting TOR: Seeking Affordable and Reliable Server Providers in Eastern Europe
by coal_norm_0v＠icloud.com 12 Sep '24

12 Sep '24

Hello everyone, I’ve been a fan of Tor for many years now, and my affinity for anonymity naturally extends to other interests, such as Monero… 😉 I’ve successfully rallied like-minded individuals who have generously supported our cause through various grants, and we’ve even received a government subsidy from the Czech Republic to promote freedom of speech in oppressive regimes. With a substantial sum of money at our disposal, we’ve chosen to allocate a portion to support the TOR project. Currently, we operate around 60 servers. Our main challenge, unsurprisingly, is with exit servers. Convincing providers to overlook automatic complaint notifications has proven quite tricky. From our original 30 exit nodes, we’re down to about 5—the rest had to be shifted to relay nodes. We could switch them to well-known operators like RDP.sh, but they already host a large number of exit nodes, and we prefer to encourage network diversity. We’ve initiated something akin to a cost-sharing model for enabling our servers to run exit nodes, but it hasn’t made a significant impact. We want to spend our funds wisely to support Tor. Do any of you have suggestions for good, affordable providers in less conventional locations (e.g., Eastern Europe like Poland, Hungary, Ukraine)? Thanks for any ideas, Alex https://tor.foundation

5 5

Artikel 5 e.V. - Another police raid in Germany - general assembly on Sep 21st 2024
by Artikel 5 e.V. 09 Sep '24

09 Sep '24

Hello to all list-reading entities! On Aug 16th 2024 German police considered it once again appropriate to raid the home&office at the registered address of our organization. The first raid was 2017. There are obviously still people working in German law enforcement today, who think that harassing a node-operator NGO would somehow lead to the de-anonymization of individual tor users. At least that is what they claim in the paperwork. As with the first time, the raid team was fortunately a bit better educated and acted significantly more reasonable than the non-technical people applying for the raid and the judge signing it off. So again, no hardware was seized. Apart from one burnt (middle relay) node and some billing paperwork for the exit node this was all about, the team left the house after one and a half hours with mostly empty hands. We intend to legally challenge the search warrant to make sure that this does not happen again (but this is not what this email here is about). These were once again one and a half hours with armed police in a personal living room, threatening to de-facto kill a livelihood and software business (carrying a truckload hardware away) of an non-profit board member to force cooperation. As a consequence, I am personally no longer willing to provide my personal address&office-space as registered address for our non-profit/NGO as long as we risk more raids by running exit nodes. That is a risk I am just no longer willing to take anymore. Artikel 5 e.V. is now calling for a general assembly on Sep 21st 2024. We are looking for new board members (who take over and organize a new registered address and keep running exits) or discuss ALL alternative options. These options include "just stop running exits" or even the most drastic step of liquidating the entire organization and distribution of the remaining budget to other German organizations (that would have to qualify under our non-profit by-laws). Assembly time&location details can be found at https://artikel5ev.de/ We intend to provide a stream primarily for our members but also for interested parties who can not attend in person. The event/stream will however be in German only. Details for the stream will be made available on the website on short notice before the event starts. If you plan to attend in person, an upfront email would be appreciated, so we can pick the right room to set things up. Thank you! Regards, Gero Kühn for Artikel 5 e.V.

3 2

Next Tor Relay Operator Meetup - September 7th, 2024 at 19UTC
by gus 08 Sep '24

08 Sep '24

Hi, Save the date: the next Tor Relay Operator will happen Saturday, September 7th, 2024 at 19 UTC! We're still working on the agenda for this meetup, however feel free to add your topics directly to this pad or just reply to the mailing list: https://pad.riseup.net/p/tor-relayop-sept7th-meetup-keep ## Agenda 1. Announcements 2. 2024 Elections & Anti-censorship news 3. Network health updates - New Metrics Network Status API 4. OTF relay operator survey summary/presentation 5. Questions & Answers <add your question below> ## How to join us Meetup details: - Room link: https://tor.meet.coop/gus-og0-x74-dzn - When: September 7th, 2024 - 19.00 UTC - Duration: 60 to 90 minutes - Tor Code of Conduct: https://community.torproject.org/policies/code_of_conduct/ - Registration: No need for a registration or anything else, just use the room-linkabove. We will open the room 10 minutes before. cheers, Gus -- The Tor Project Community Team Lead

3 5

simple instructions to the expiredkey issue, pls.?
by code9n＠pm.me 06 Sep '24

06 Sep '24

Hi, I know I should have sorted this some weeks ago but can anyone tell me a simple method of dealing with the: bullseye InRelease: The following signatures were invalid: EXPKEYSIG 74A941BA219EC810 deb.torproject.org archive signing key issue, please? Thanks.

4 4

Bridge node configurations and where to find them (semi quote)
by Alessandro Greco 30 Aug '24

30 Aug '24

Dear all, In the past, I set up a middle relay node, and today I am looking to experiment with configuring a Bridge node to support the Tor project and its community. Since this is a very sensitive task, I decided to reach out to you to ensure that the setup is correct and that the configuration does not pose any risks to users who connect. First, I will summarize the `torrc` configuration file (I have removed the ports as they differ from the standard ones): ``` BridgeRelay 1 ORPort <port> ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 0.0.0.0:<port> ExtORPort auto ExitPolicy reject *:* ``` I have set two limits on the connections: ``` BandwidthRate 300 MBytes # I want to determine how much bandwidth I can allocate without impacting my network usage. IPv4Only ``` As for the information settings, I have used the usual `ContactInfo` and `Nickname`. While reading the `torrc` documentation, I discovered the Sandbox feature, which is still in development. In this regard, I would like to ask whether using experimental features like this on Bridge nodes is advisable or not. Personally, I would find a feature like this very useful. Should an anti DDoS system be configured? I wanted to ask how I can further contribute to the Tor Project's research, as I have read that there are "Statistics" features that allow the collection of useful information for the developer community. I have two main questions about this: 1. Is it advisable to use experimental features or those that collect information on a Bridge node (assuming there is a difference between a Bridge, a Guard/Middle relay, and an Exit Node)? 2. If the answer to the first question is yes, what are all the features that I can include in the `torrc` file to passively support research within the Tor Project? Finally, I would like to ask what information should be kept confidential when managing a Bridge. For example, I know for sure that it is important to keep the IP address confidential to avoid the risk of being blacklisted, but are there any other pieces of information that need to be protected? To ensure that a Bridge node can be restarted on a different machine, which files need to be preserved? Are they the same as those for a standard relay (i.e., the private key), or are there additional files that need to be securely stored? Thank you for your support and guidance. Best regards, Aleff --- Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get&search=0x7CFCE404A2168C85 Join to support: - Free Software Foundation! (my.fsf.org/join?referrer=6202114) - Electronic Frontier Foundation! (eff.org) - Tor-Project (torproject.org) - Signal (signal.org)

3 6