- tor-relays - lists.torproject.org

Fwd: Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes
by Sam 07 Aug '24

07 Aug '24

Hello, as tb discussed further with developers of Tor, the concept of "Reflec-Tor"s (and Exit-Nodes to be seen also as an Entry-Node) might have an impact like Snowflakes for Chat and Messaging over Tor and addresses opinions of Relay admins and university research too. Regards ---------- Forwarded message --------- Date: Di., 16. Juli 2024 um 20:36 Uhr Subject: Fwd: Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes To: <tor-dev(a)lists.torproject.org> System wrote via Tor Project <noreply(a)forum.torproject.org>:Feedback: Please submit the proposal also to tor-dev: tor-dev Info PageIntroducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes https://www.reddit.com/r/TOR/comments/1e4te8m/introducing_discussing_reflec… ==============================================================Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes *Tor-Messaging: Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay |* Hello, I think this belongs to this core, general, relay topic-forum, as it is also a development & community issue, request and efford, I post it here into the reddit forum for your core discussion: The idea is to add next to Bridges, Relays and Exit-Nodes also "Entry-Nodes" as "Reflec-Tor"(s) to the point of Exit-Nodes. Hence: Exit-Nodes are developed futher to be also an Entry-Node. Some may remember when gnutella got hybrid with edonkey and then also with torrent, Mike Stokes from Shareaza did that. The idea today, 20 years later, is to add some Echo-capabilities to Tor in regard of the servers for Exit and Entry. *Vision: Every (updated) Exit-Node is an Echo-Server - For a better Tor-Messaging.* What does that mean? An Echo-Server is a server for chat-messaging to send an incomming message packet again out to all connected clients at the moment. Ping-in and Ping-Out to all. That simple, that's why it is called the Echo. Like a shout in front of a forrest, all connected users can hear and get the (encrypted) shout or message or packet back from the tree wall. There are 3 software applications for Echo-Servers: - https://github.com/textbrowser/spot-on (Desktop, sercer in the Listener Tab) - https://github.com/textbrowser/smokestack (java for Android) - https://github.com/textbrowser/spot-on-lite (headless deamon for Linux) Now, the Listener function with ping in and ping out should be implemented within a Tor-Exit-Node. When it comes to Tor-Messaging, there are some pathes possible: A) Tor-Chat-Client-Alice - Tor - Internet - Echo-Server - Internet - Tor - Tor-Chat-Client-Bob (Tor-proxied Chat-Server, which only accepts encrypted packets) B) Tor-Chat-Client-Alice - Echo - Tor - Tor - Echo - Tor-Chat-Client-Bob (Echo Tor-tunneled) C) Tor-Chat-Client-Alice - Echo-Server - Tor-Chat-Client-Bob (direct connection to Echo-Server with only encypted packets) The request here is to build and develop option A. That is just right now also possible, by an Exit-Node of Tor running the Echo-Server-Software on the same machine in parallel. Just the port is different. This is an idea for some might be new, but thinking Tor Messaging a bit, it comes quickly to this ideas and better soluttion. The way to connect D) Tor-Chat-Client-Alice - Hidden Onion Server v3 - Tor - Tor - Hidden Onion Server v3 - Tor-Chat-Client-Bob is the current given way for clientes like RicoChet Refresh, Quiet or Cwtch. Similar to Briar, even developers of such clients above tell the loss of messages and low reliability of the hidden to hidden path. Some of you might know, that there were use cases with missing messages in a range of 35-45 %. Don't quote me on that, but as core developers and community members you might be in contact with those who experience this. Furthermore the Messaging clients are not advanced in functionality, nor advanced in strong encryption. It would be third a long development way to got that route. It is cost effective and needs cappable developers. Some project have stamped on and made a workable client, but does that unite all our power in the sense of Tor-Messaging? Messaging needs a Vision and Statement from the Tor-Core-Developer team with a discussion in the community in that regard with honor to the individual projects and also with support for their chosen path (Model D). At the same time we have to state that it is as it is, a HTTP-Server in the middle like in Model A is faster than Model D. In the graph-path the Echo-Server in the middle handles only encrypted traffic, so it is just like another Relay. We can call it "Reflec-Tor". The only sense it to multiply incomming encrypted packets from one node to all connected nodes. With that Idea, the Messenger Spot-On could be used as a Tor-Messenger. This Messenger has stong encryption and is full of feature for messaging and also cryptography. it is like adding Firefox to Tor-Browsing, when Spot-On is added to Tor-Messaging. Something to read at the community forum: https://www.reddit.com/r/Spot_On_Encryption/ Also there is a Mobile Client for Android, which also connects to Reflec-Tors, find "Smoke" Messenger at F-Droid.org. Please, get this right, it is not about a technical view on slow and failing chat-packets to hidden servers, and it is not about those start-up clients using this inside technology, some do a good project. It is about the idea, that an Reflec-Tor mirroring and pinging back packets on the Exit-Node this hop within the path of tor is not outside, it is always fully encryted for the messaging packets and should be seen as one Tor-Path, especially if the Listener-Ping-Back function (the Echo capabilities) is build in the Exit-Node-Tor Software. Spot-On is already a Tor-Messenger - as it uses also HTTPs and it sends only encrypted packets. *A test is easy to make:* (1) Start the Tor-Browser, which has always the Port 9051 to Tor, Tor is running. Next to Surfing with Tor-Browser Firefox the Chat with Tor-Messenger Spot-On can start. (2) Start Spot-On on a webserver and create in the Listeners Tab a Listener on Port 4710. (3) Start two Spot-On Instances Alice and Bob on two Laptops, in the Neighbors Tab you connect the Webserver via Tor: Add the IP and Port 4710 to the neighbor and choose Proxy: 127.0.0.1 Port 4710. You get the the Path: Tor-Chat-Client-Alice - Tor - Internet - Echo-Server - Internet - Tor - Tor-Chat-Client-Bob The idea is now to integrate this a bit more: Tor-Chat-Client-Spot-On-Alice - Tor - [Tor-Exit-Node also Reflec-Tor (Echo-Server)] - Tor - Tor-Chat-Client-Spot-On-Bob You see, the way stays all within the Tor-Family. For sure, in case Alice does not want to use Tor, she also can message to Bob, who is behind Tor. Tor-Chat-Client-Spot-On-Alice --> [Tor-Exit-Node as Entry-Node also Reflec-Tor (Echo-Server)] - Tor - Tor-Chat-Client-Spot-On-Bob The IP of an Entry-Node is shown in the Tor-Browser and can get a port added. Then two user can simply cata over that node. We need in times of surveillance, data retention, chat control and for sake of the needs of whistleblowser and people who want to chat privat and anonymously more decentral and open source chat server. *The mission is: Every Tor-Exit Node is an Entry-Node for Chat.* It should be not a lot of code to be added to the ports of an Exit-Node and displaying the Port of the Exit-Node in the Tor-Browser path icon. This makes sense in several effects to be discussed and developed further: - Taking the next Development Step for Tor-Messaging: BTW, A Forum about Tor-Messaging could be made as a category here in the forum please. - directly support Tor-based Messaging for the Spot-On Messaging client To be developed and discussed is, if this infra-structure could help to - support bootstrapping of Tor - support Censorship circumvention of Tor Reflec-Tors as SnowFlakes over the Messenger with EPKS - Accept, that some routing to an HTTPS internet server at the Tor-Node is faster than to an hidden onion server at the Tor Node. Well, to add some "ping-in-and-out" for an packet is what every netcat and socat under linux can do. It is a small development step to make each Tor-Exit node a free chat server for messaging, which is a big step for mankind to have a network of free messaging chat servers. Lets also see, how users and community will test and develop this messaging. So it is not only a discussion for developers, it is also a step forward the needs of the communities *for a free internet:* - *for chat and their discussions.* A few code lines to exit nodes make them a Reflec-Tor and messaging over Tor can start really decentral and open source and free. *What do you think?* does this privacy-concept bring more privacy and reliability in packet delivery to messaging with Tor? Regards

3 3

Opening metrics-api.torproject.org for testing
by Hiro 03 Aug '24

03 Aug '24

Hello everyone, As part of our redesign of the metrics pipeline, we have developed a new API that will eventually replace Onionoo: the Network Status API (aka NSA). We are now opening NSA for testing, and it can be accessed at: https://metrics-api.torproject.org. Documentation is available here: https://gitlab.torproject.org/tpo/network-health/metrics/networkstatusapi/-…. Please note that the API may be unstable at times, and some results might be inconsistent. Onionoo will remain our primary data source for relay search at least until the end of the year. We welcome any suggestions or feedback regarding the types of information that should be included in the API. You can provide feedback by opening an issue on the repository or by replying to this email. Thank you. -hiro

4 3

Tor Metrics 'Running' flag is back for bridges who don't publish the OrPort
by lists＠for-privacy.net 30 Jul '24

30 Jul '24

I don't know if this was mentioned at the Tor Relay Meeting yesterday, if so, I missed it. ;-) A few months ago there was a recommendation to not exposing OrPort for bridges. This had the unpleasant effect that all bridges were 'red' on Tor Metrics, even though they were running perfectly fine. I noticed yesterday after the meeting that everything is 'green' again. https://metrics.torproject.org/rs.html#search/ForPrivacyNET Thank you, I believe these 6 people did that: https://gitlab.torproject.org/tpo/network-health/team/-/issues/318 -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

5 7

Re: [tor-relays] Archive key from deb.torproject.org was renewed!
by boldsuck 25 Jul '24

25 Jul '24

On Donnerstag, 25. Juli 2024 01:29:41 CEST you wrote: > What was the previous key for reminder? The same ;-) > This looks like exactly the one I installed BEFORE all your messages > mentioning the requirement to update... manually. Of course, it is the same key as before. When creating PGP keys, an expiration date is defined by default. The Repo PGP key is always valid for 2 years and the expiry date has been extended for the next 2 years. > I have a problem in that I like to remove ssh before I leave my > installations, to be conscious. What do you mean exactly? 'exit', and you are logged out. > I would have to re-install yet I am pretty sure my key was also 89-ending. > > QUESTION: > > is there any one / way to tell whether my relays have the proper key > from any metrics / torproject admin / version showing up? apt update gives error message that key has expired. apt-key -list /etc/apt/trusted.gpg.d/deb.torproject.org-keyring.gpg ----------------------------------------------------- pub rsa2048 2009-09-04 [SC] [expires: 2028-08-29] A3C4 F0F9 79CA A22C DBA8 F512 EE8C BC9E 886D DD89 uid [ unknown] deb.torproject.org archive signing key sub rsa2048 2009-09-04 [S] [expires: 2026-09-09] -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

1 1

OT: Tor Control Protokoll ADD_ONION
by boldsuck 24 Jul '24

24 Jul '24

Hi, In the control-spec https://spec.torproject.org/control-spec/commands.html#add_onion or https://github.com/torproject/torspec/blob/main/control-spec.txt#L1777 The ADD_ONION 'Flag' include Hidden Service options: MaxStreamsCloseCircuit and MaxStreams, among others. We also want to use the PoWDefenses and IntroDoSDefense parameters. Is the control-spec outdated or is it not possible to set these parameters via Flag? -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

1 0

OT: Tor-Metrics for Hidden Services
by boldsuck 24 Jul '24

24 Jul '24

Does anyone know where I can find information about the MetricsPort output? In particular, hs introduction point and rendezvous point circ build time bucket. What do the numbers represent le="1000.00" - le="6000.00" suggested-effort value Do I understand correctly that the value goes from 0-1000? https://spec.torproject.org/hspow-spec/common-protocol.html#client-limits # HELP tor_hs_intro_circ_build_time The introduction circuit build time in milliseconds # TYPE tor_hs_intro_circ_build_time histogram tor_hs_intro_circ_build_time_bucket{onion="somerandomonionaddress",le="1000.00"} 128 tor_hs_intro_circ_build_time_bucket{onion="somerandomonionaddress",le="5000.00"} 205 tor_hs_intro_circ_build_time_bucket{onion="somerandomonionaddress",le="10000.00"} 205 tor_hs_intro_circ_build_time_bucket{onion="somerandomonionaddress",le="30000.00"} 205 tor_hs_intro_circ_build_time_bucket{onion="somerandomonionaddress",le="60000.00"} 205 tor_hs_intro_circ_build_time_bucket{onion="somerandomonionaddress",le="+Inf"} 205 tor_hs_intro_circ_build_time_sum{onion="somerandomonionaddress"} 210297 tor_hs_intro_circ_build_time_count{onion="somerandomonionaddress"} 205 # HELP tor_hs_rend_circ_build_time The rendezvous circuit build time in milliseconds # TYPE tor_hs_rend_circ_build_time histogram tor_hs_rend_circ_build_time_bucket{onion="somerandomonionaddress",le="1000.00"} 14275 tor_hs_rend_circ_build_time_bucket{onion="somerandomonionaddress",le="5000.00"} 24060 tor_hs_rend_circ_build_time_bucket{onion="somerandomonionaddress",le="10000.00"} 24095 tor_hs_rend_circ_build_time_bucket{onion="somerandomonionaddress",le="30000.00"} 24096 tor_hs_rend_circ_build_time_bucket{onion="somerandomonionaddress",le="60000.00"} 24096 tor_hs_rend_circ_build_time_bucket{onion="somerandomonionaddress",le="+Inf"} 24096 tor_hs_rend_circ_build_time_sum{onion="somerandomonionaddress"} 25308501 tor_hs_rend_circ_build_time_count{onion="somerandomonionaddress"} 24096 # HELP tor_hs_pow_suggested_effort Suggested effort for requests with a proof of work client puzzle # TYPE tor_hs_pow_suggested_effort gauge tor_hs_pow_suggested_effort{onion="somerandomonionaddress"} 1 -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

1 0

bridges
by Earl M. Northern 22 Jul '24

22 Jul '24

obfs4 49.12.224.203:8001 8E6B9FB7914E9ECA1BD271AB33FF8D868EEA6DE5 cert=zZcPgBgVxKhmhlo2M0yLKTGkxDnSXl2372d5E0POqVMpmzu0tsIlegXR4OolUDudfD+7CA iat-mode=0 obfs4 94.131.97.25:50703 4DF9058B33F6D3E72A4397B09A40503AF51DAA04 cert=HXw+QS4SVjB9/oekpZSQcGDyoNxrp8a/mOQ14qSAuLPp5b9h6H1p4VB8008VHWPwj7vBJA iat-mode=0 obfs4 88.198.12.66:1812 7611DAC3C59A43322D774400F57FDA4D2AC0EEE2 cert=Qo94bPwOyZ9gRUJkyXFV5AhLXOPa+Ilgt8gQ+5a2Mw2NSzzvEY00FhWfeCnfSGs81CYLZA iat-mode=0

3 2

tor middle relay issue
by theyarewatching 22 Jul '24

22 Jul '24

I have had two ubuntu based tor middle relays fail.I am using a proxmox server and have tried both ubuntu server 20.04 and a fresh download of ubuntu 24.04. I follow the tor website install instructions. The results show the same no matter what version of ubuntu. "failed to start Tor(a)default.service. This is the same result with the original install and a brand new VM install on Proxmox. Any input would be greatly appreciated Thank you SDS

1 0

OOM at relay with small RAM if statistic configs are enabled
by Toralf Förster 14 Jul '24

14 Jul '24

Regarding to https://gitlab.torproject.org/tpo/core/tor/-/issues/40958 I do wonder if that issue happened for stable Tor versions too - I do run myself git HEAD only. FWIW at my bare metal relay the RAM consumption per Tor process decreased by about 0.7 GiB. -- Toralf

1 0

Hardware sizing for physical exit node
by Osservatorio Nessuno 11 Jul '24

11 Jul '24

Hi everyone, we are planning to get some hardware to run a physical Tor exit node, starting with a 1Gbps dedicated, unmetered uplink (10Gbps downlink). We will also route a /24 on it, so we will have large availability of addresses to run multiple instances. We have been running a few exit nodes so far, but never on our own hardware. Which is the bandwith limit per core/Tore instance? Or what can we expect to be the bottleneck? Due to some other requirements we need for some experiments (SFP ports, coreboot support, etc) we can mainly choose between these 2 CPUs: Intel i5-1235U Intel i7-1255U The cost between the two models is significant enough in our case to pick the i7 only if it's really useful. In both cases with 32GB of DDR5 RAM (we can max to 64 if needed, but is it?). Should this allow us to saturate the uplink? To summarize, with this bandwith, this hardware and a /24 how many Tor exit nodes should be ideal to run considering that each of them could have their own address? Thanks!

5 4

Seeking Advice on Running Multiple Tor Relays or A Bridge
by Alessandro Greco 07 Jul '24

07 Jul '24

Hello Tor Community, I have some experience running a Tor relay, and I am now interested in setting up another one. I plan to do this using my home internet connection, which is an FTTH line with bandwidth up to 2 Gbps. I have read that it is possible to run multiple relays on the same node, but I am unsure how to configure this. Additionally, I am curious about what would be most beneficial for the Tor network today: a highly resilient bridge or multiple relays managed from the same node? Is it feasible to operate both at the same time? This is probably not the best idea since the bridge's IP address would be public, right? I am looking for guidance on the best course of action to support the Tor community. Thank you in advance for your assistance,Aleff.

4 5

Re: [tor-relays] Seeking Advice on Running Multiple Tor Relays or A Bridge
by 0tpcqovw＠duck.com 07 Jul '24

07 Jul '24

For what it's worth, in addition to my Tor Bridge Relay, I also run two Snowflake Proxies on my home LAN. Malcolm On 6 July 2024 19:14:23 GMT-03:00, "Gary C. New via tor-relays" <tor-relays_at_lists.torproject.org_0tpcqovw(a)duck.com> wrote: >Alessandro, > >I would recommend running bridges (opposed to relays) on a home network to avoid browing issues with your bank, news, etc as these entities often block Tor relays and not bridges. >Respectfully, > >Gary > > On Saturday, July 6, 2024, 3:07:52 PM MDT, Roger Dingledine <arma(a)torproject.org> wrote: > > On Sat, Jul 06, 2024 at 06:34:37PM +0000, Alessandro Greco via tor-relays wrote: >> I have some experience running a Tor relay, and I am now interested in setting up another one. I plan to do this using my home internet connection, which is an FTTH line with bandwidth up to 2 Gbps. > >Thanks for running a relay! > >> I have read that it is possible to run multiple relays on the same node, but I am unsure how to configure this. > >If you're using the tor deb (e.g. on Debian or Ubuntu), it comes with >a tool to set up multiple tors. "man tor-instance-create" to get started. > >There is also the possibility of using the fancy automated >deployment tools that some of the bigger relay operators here >use, which probably only makes sense if you are already familiar >with these automation tools (a popular one based on ansible: >https://github.com/nusenu/ansible-relayor ). > >In either case, make sure you have enough memory in your system to >handle each Tor relay: relays can use 1 or 2 gigabytes of memory each >during normal operation, but when the network is under load it can go >much higher than that. > >> Additionally, I am curious about what would be most beneficial for the Tor network today: a highly resilient bridge or multiple relays managed from the same node? > >If you have the bandwidth (which it sounds like you do), the multiple >fast relays will be much more useful to the network. > >See also https://2019.www.torproject.org/docs/faq#RelayOrBridge > >> Is it feasible to operate both at the same time? This is probably not the best idea since the bridge's IP address would be public, right? > >It is technically possible yes, but as you say, having a public relay >on the IP address will undermine the effectiveness of your bridge on >that IP address. > >The same logic is also why we don't recommend running two different >kinds of bridges on a single IP address: if one of them gets discovered >and the censor blocks by IP address, then the other will stop working too. > >> I am looking for guidance on the best course of action to support the Tor community. >> Thank you in advance for your assistance,Aleff. > >Thanks for wanting to help! > >--Roger > >_______________________________________________ >tor-relays mailing list >tor-relays(a)lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

1 0

Quick Assist Technology and Tor?
by mail＠nothingtohide.nl 25 Jun '24

25 Jun '24

Hi o/, During the Tor Operator Meetup I asked about Quick Assist Technology (QAT) support and was asked to bring it to the tor-relays mailing list so the network team can take a look at the question. In 2025 we're going to build one or more new servers and we're looking in to optimizing the performance per watt ratio since some of our current servers are rather power hungry ;-). I'm wondering whether QAT works for Tor to offload compression, hashing and encryption. In theory, looking at the nature of Tor (a lot encryption), this could result in a huge performance boost of 100-300% (based on other hashing, cryptographic and compression offload benchmarks). Support for QAT also has improved considerably over the years so many programs/workloads already work nicely with it, but I'm not sure about Tor. It looks like Tor uses [1] RSA-1024, AES-CBC, AES-CTR, Curve25519, Ed25519, SHA1, AES256, AES3-256. Most (no Curve- and Ed25519) should in theory also work with QAT [2] (although I guess only a few would impact performance significantly when offloaded). But the question is: does it really work? If not, what would be needed to make it work? Are there Tor operators who already utilize QAT? Does the Network Team have some insight in to this? :) Some of the potential advantages when comparing a similar amount of traffic: - Lower power consumption (much cheaper to run in expensive European countries). - Less CPU cycles required (= cheaper CPUs). - Less heat/cooling required (easier to put in distribution boxes and other small places). - Smaller physical footprint (easier to put in distribution boxes and other small places). - Alleviates some of the issues and challenges caused by Tor's single threaded architecture by effectively increasing bandwidth per CPU core considerably. With regards, tornth [1] https://spec.torproject.org/tor-spec/preliminaries.html?highlight=cipher#ci… [2] https://www.intel.com/content/www/us/en/support/articles/000093843/technolo…

4 4

Why should we avoid adding bridges fingerprints in MyFamily?
by Edward Cage 24 Jun '24

24 Jun '24

Hi all, Quick question about the fingerprints of our bridges. It's clearly written in torrc that we should not include them in MyFamily. I don't well understand why, especially because: - Every bridge, and their fingerprints, are publicly listed on Tor Metrics; - The contact email is disclosed for each of them, and it allows our bridges and relays to be easily linked to a same operator. (or should we use a different email address for each bridge?) Best regards

2 1

Next Tor Relay Operator Meetup - June 22, 2024 at 19 UTC
by gus 23 Jun '24

23 Jun '24

Hello, Please save the date: the next Tor Relay Operator will happen Saturday, June 22 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-june22-meetup-keep ## Agenda 1. Announcements - EOL work: bridges running 0.4.7.x were rejected from the network: https://lists.torproject.org/pipermail/tor-relays/2024-June/021678.html - Snowflake extension issue: https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/142 - Farahavar directory authority is back! https://gitlab.torproject.org/tpo/core/tor/-/commit/39ba9ce0d7913ceb53fc1f1… 2. Network Health - Reports of relays ddos & ongoing onion services overload 3. Policy and proposals discussion: - https://gitlab.torproject.org/tpo/community/policies/-/issues/22 4. Next events - Tor presence at DEFCON, Las Vegas - Summer break & next Tor Relay Operator online meetup 5. Questions & Answers <add your questions here> ## How to join us Meetup details - Room link: https://tor.meet.coop/gus-og0-x74-dzn - When: June 22, 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

2 2

Tor non-exit list
by Carsten Otto 22 Jun '24

22 Jun '24

Hi Dan, For reference: https://www.dan.me.uk/dnsbl https://www.dan.me.uk/tornodes https://www.dan.me.uk/torlist/?full First of all, thank you for your tools and other contributions. The mere fact that your DNS blocklists are used by countless vendors should be a compliment in itself, and I'd be happy to have that much impact with my own projects. As you already state on your own site ("Please think carefully before choosing to use this list for blocking purposes"), your non-exit Tor relay list is a bit unusual. I'm running ftp.halifax.rwth-aachen.de, a major file mirror serving around 30 TByte of data at around 4 GBit/sec (on average). Recently, we added Tor relays on the same IP address, and your list correctly picked this up (137.226.34.46). Now, I'm writing as this caused quite a lot of mayhem. Several "security" appliance vendors didn't "think carefully" before adding your non-exit list to their devices. Among those are Arbor Prevail, Check Point, Ubiquiti (UniFi) - feel free to search for "ET TOR Known Tor Relay/Router (Not Exit) Node" to see the effect of this. In addition to private users making use of such devices, several banks/corporations/institutions started blocking our IP address, causing some frustration with us and their admins, as their Linux/Jenkins/... updates suddenly stopped working. As you might have guessed, changing "security" configurations (even if they may be wrong or questionable) is quite a challenge, and in some cases the (motivated) admins weren't unable to fix this issue on their end. As you seem to be well aware of what Tor is, what an exit relay does and what a non-exit relay does, would you be willing to retire the non-exit blocklist (at least the part that can be used for automated blocks)? I'd argue that the current setup does more harm than good (assuming you agree that Tor is a good thing in general). I'd be happy to discuss pros and cons, but ultimately that's your decision to make. Thanks Carsten -- Dr. Carsten Otto http://verify.rwth-aachen.de/otto/

5 6

Relay usage dropped 9x when enabling UFW. What UFW rules do other relay operators enact?
by admin＠likogan.dev 19 Jun '24

19 Jun '24

Hello all, I'm running relay 292FCACE773DC259B799914A23BE65A6A6178E8F and have noticed traffic drops when enabling UFW. Around 2024-01-15, I enabled UFW on this server. I noticed a 9x drop in traffic (10.88M -> 1.708M), and coughed it up to relay weirdness. This is about when my relays Guard status would randomly drop every few weeks. I finally got fed up with this huge drop in traffic on 2024-06-11 and was about to reinstall my server OS. This is when I decided to disable UFW and found that my traffic went back over a few days (2.215M -> 8.948M). Here are my tor-related UFW rules; To Action From -- ------ ---- [ 3] 9001 ALLOW IN Anywhere [11] 9001 (v6) ALLOW IN Anywhere (v6) I'm really confused how UFW firewalled most, but not all, of my relays traffic. What UFW rules do other relay operators enact? Thanks, Likogan

3 2

Re: [tor-relays] Relay usage dropped 9x when enabling UFW. What UFW rules > do other relay operators enact?
by zorc 19 Jun '24

19 Jun '24

Hi Likogan, > What UFW rules do other relay operators enact? I'm running 4CEAFCE5841C0DAE30164B4F59452F7F4D818A67 on Linux Mint 21.3 (should be close to Ubuntu Jammy) with UFW enabled, and don't have any issues. I have the same two rules for Tor as you do. I can imagine three things: 1. To me it looks like you have other rules before your Tor rules. Are any of them rate limiting? 2. I don't run an exit node, so I don't know how UFW would behave in that case. 3. Do you have logging rules? I once had issues with my router running out of CPU due to some logging rules being triggered by Tor-related traffic (potentially malicious). Maybe UFW could achieve something similar? Hope that helps. Cheers, zorc

1 0

Which choice is better
by theyarewatching 18 Jun '24

18 Jun '24

Hello all, I have been operating 8 middle relays for several months and due to my internet service limitations I have to make some changes. I have cox panorama service in the USA and for the most part it works well. My dilemma is with all of my VMs running and relays etc it tends to overload my connection. This causes my household streaming to drop off and my fam is not happy with me. The question I have for you is the following. Which is preferable; four middle relays running with no limits or eight middle relays with speed limits? I am asking which would be better for the network? I'll await your answers Thanks for the input SDS

2 1

Relay migration
by Eldalië 17 Jun '24

17 Jun '24

Hello everyone. I have to move somewhere else a a (middle) relay I have been running for a few years. It will be down for 2-4 weeks, then be back online in a different location, with different ISP, at better speed. But it will run on the same hardware and software. Should I keep the same keys, or start from scratch? -- Eldalië My private key is attached. Please, use it and provide me yours!

5 6

Disable instance
by mailinglistreader＠riseup.net 14 Jun '24

14 Jun '24

I ran into a problem with instances. On some of my servers I noticed that the performance decreased when running a node for each CPU (more than 2 virtual CPUs on those systems). So I disabled the newest node on those systems with "systemctl disable tor(a)instancename.default" without getting a output. But after an TOR update or reboot of the system, that instance is up again. Is it enough to (re)move the instance folders in /etc/tor/instances and /var/run/tor-instances, or do I have to look in another location as well?

2 1

[proposal] Guidelines for sustainability and incentivization proposals in the Tor Community
by gus 13 Jun '24

13 Jun '24

Dear relay operators, We invite all Tor relay operators to join the discussion about the "Guidelines for sustainability and incentivization proposals in the Tor Community". For your convenience, the proposal text is included below. If you prefer reading the markdown version, you can find the latest draft in the Community policy repository on Gitlab[1]. Similar to the contact info proposal discussion[2], the guideline proposal will follow the established process described in our meta proposal policy[3]. [1] https://gitlab.torproject.org/tpo/community/policies/-/issues/22 [2] https://gitlab.torproject.org/tpo/community/policies/-/issues/17 [3] https://community.torproject.org/policies/relays/001-community-relay-operat… """ ``` * Filename: xxx-guidelines-for-sustainability-and-incentivization-proposals.md * Title: Guidelines for sustainability and incentivization proposals in the Tor Community * Author: gus - gus(a)torproject.org * Created: 2024-06-11 * Status: Open ``` ## Overview This document outlines guidelines for sustainability and incentivization proposals for the Tor community. The guidelines are designed to prevent exploitative and abusive practices and preserve the volunteer-driven nature of the Tor community. We want to ensure that Tor remains an open and inclusive network and community for all users and contributors, and, at the same time, we want to encourage proposals to support and sustain the Tor network. ## Motivation The Tor community is shaped and driven by the principles outlined in the Tor Project's [Social Contract](https://community.torproject.org/policies/social_contract/), [Code of Conduct](https://community.torproject.org/policies/code_of_conduct/), and other policies such as the [Expectations for Relay Operators](https://community.torproject.org/policies/relays/expectations-fo…. The Tor network is powered by a diverse community of operators, also known as relay or network operators. The Tor network is the backbone of Tor and relies on the collaboration and support of thousands of volunteers, who donate their resources and bandwidth to ensure that users all around the world can access the free and open internet in a secure and anonymous way. Managing relays can create extra costs and expenses, for example, the cost of bandwidth, new hardware, dedicated IPv4 addresses, and, when operating exit nodes, in a few cases, legal costs. While some volunteers are able to cover the operational costs by themselves or by associating with others friends, growing the Tor network in a diverse and sustainable way is one of the open challenges for non-profit networks. There are multiple and different approaches to achieve this goal. As a non-profit organization, we seek proposals for sustainability and incentivization that may include financial resources, yet our primary goal is not to transform our community into a for-profit business. Shifting from a collaborative framework to a for-profit business model can impact the dynamics of the Tor Community and introduce new legal challenges. While many countries permit the operation of a Tor relay, shifting to a paid or for-profit service model could reclassify the network as a "commercial service provider", subjecting it to a different set of legal requirements and obligations. You can read more about the problem of for-profit models on the Tor blog post: [Safeguarding the Tor network: our commitment to network health and supporting relay operators](https://blog.torproject.org/tor-network-community-health-update/). ### Sustainability models over for-profit models It's clear for the Tor Project that sustainability proposals, including both financial and non-financial rewards, must enhance collaboration and help the community to grow, rather than marginalize contributors and undermine the volunteer-driven nature of the network and the Tor community. The proposals must respect and maintain the Tor relay operator community diversity while aligning with the goals and mission of the Tor Project. Incentivization proposal refers to a plan, scheme or strategy designed to encourage specific behaviors or actions through various incentives such as swag, gamification, or virtual points (e.g. Reddit's karma). Acceptable incentives primarily encompass non-financial rewards that recognize and motivate the community's contributions. Examples of such incentives include public acknowledgment, rewarding operators with [Tor swag](https://community.torproject.org/relay/community-resources/swag/), highlighting their contribution on Tor social media channels, inviting operators to the Tor Project in-person events, and so on. These incentives are designed to value the community's commitment without introducing monetary motivation, which could potentially erode the collaborative nature of volunteer participation. They aim to reinforce the intrinsic motivation of contributors, with a sense of belonging and achievement, while avoiding the complexities and potential conflicts associated with financial compensation. The guidelines described in this document ensure that sustainability and incentivization proposals are developed and managed transparently, fairly, and in the best interest of the Tor community, free from undue influence or bias. ## Guidelines for sustainability and incentivization proposals As outlined above, contributors willing to work on such proposals, must follow these guidelines: [Table of Content] 1. Policy compliance 2. Preservation of the Tor Community collaboration and its spirit 3. Innovation must preserve and respect the Tor Community diversity 4. Regulation of fundraising campaigns, donations and reward systems 5. No fee or "donation" for participation or to "unlock" rewards 6. Fraud, cheating, and abuse prevention in Tor incentives 7. Conflict of Interest Policy 8. Reporting scammers and avoiding risks 9. Frequently Asked Questions ### 1. Policy compliance - Any sustainability or incentivization proposal for the Tor network and the relay operator community, must comply and adhere to the Tor Project's [Community Policies](https://community.torproject.org/policies), including but not limited to the Tor Project Code of Conduct, Social Contract, Statement of Values and must follow the process described on: [Process for new policies and proposals for the Tor relay operator community](https://community.torproject.org/policies/relays/001-community-r…. - Proposals and projects must follow and comply with the Tor Project [Trademark](https://www.torproject.org/about/trademark/) policy. Don't use Tor in your product name or domain name. Creating a new brand that incorporates the Tor brand is likely to lead to confusion, and commercial confusion is a sign of trademark infringement. - Incentivization proposals or schemes of any nature that jeopardize this policy will lead to the removal of the authors and collaborators from the Tor network and the Tor Community. ### 2. Preservation of the Tor Community collaboration and its spirit Proposals must incentivize collaboration and sustainability of the Tor Community: - The Tor network operates as a non-profit and a collaborative community. - Rewards and incentivization proposals whether they involve monetary elements or not (like gamification strategies), must not disrupt the collaborative foundation of the Tor operator community. - The goal is to build a trusted Tor relay operator community, dedicated to defend and promote the Tor mission, rather than motivated and driven by individual financial profit. - For example, simplifying the process to facilitate the creation of local Tor relay associations is a proposal that respects and preserves the Tor Community. ### 3. Innovation must preserve and respect the Tor Community diversity - We encourage innovative collaboration methods that promote inclusivity, diversity, and the growth of the Tor network and our Community of operators. - These methods should not put our users and contributors at risk or be in detriment of our core values. - We do not believe that there is only one model or a single path to incentivize or sustain relay operations. We believe that Tor relay operators and contributors have different motivations and sustainability proposals must ensure that they are preserving and respecting the Tor Community diversity. ### 4. Regulation of fundraising campaigns, donations and reward systems It is crucial to draw a clear distinction between genuine donations made in support of the Tor Project's mission and exploitative financial schemes (aka pyramid or Ponzi schemes) aimed solely at profiting from the network's resources without contributing to the health of the Tor network and advancing Tor's mission. For instance, relay associations conducting their fundraising activities, such as selling t-shirts, are definitely aligned with the mission of the Tor Project and this policy. In this context, proposals involving any kind of reward or financial systems, such as tokens or cryptocurrencies, must seek and obtain formal and written approval from the Tor Project Executive Director before its implementation or any stage of execution (for example, promotion and outreach). Failure to proactively seek approval will lead to the exclusion of the project and its affiliates and associated from the network and Tor Community. Furthermore, legal measures may be pursued to rectify any financial or reputational harm incurred as a result of such actions. Vetting central entities: Proposals involving central entities such as collective wallets, Decentralized Autonomous Organizations (DAOs), or other intermediaries should be approached with caution and require approval by the Tor Project. These entities must be clearly identified and evaluated for their reliability, and the potential risks they pose should be thoroughly assessed. This includes considerations of their possibility to misbehave, for example, they could refuse service, could extort relay operators by demanding extra fees in order to release their reward, or could 'inflate' the digital currency (coins, tickets, guesses, etc.) by printing its own tokens for a profit, as highlighted in Rob Jansen's [research and blog post](https://blog.torproject.org/tor-incentives-research-roundup-goldstar-…. Consent for fund handling: It is mandatory for operators and intermediaries to obtain clear and explicit consent (written approval) before claiming or managing funds on behalf of others. This rule is crucial to maintain the transparency and trust within the community. Prohibition of unofficial financial activities: Unauthorized fundraising or financial activities conducted by intermediaries, especially those claiming to act on behalf of other operators without explicit consent and approval from The Tor Project, are strictly forbidden. Such activities, if promoted, posted, or shared on Tor communication channels (such as forums, mailing lists, chat channels), will lead to the immediate removal of the content and the exclusion of the individuals and entities responsible. Whether formally registered or operating on an informal basis, all Tor relay operators are authorized to launch fundraising and donation initiatives to support their ongoing non-profit relay operations within the Tor network. It is advised and recommended to handle the donations in a transparent way. This can be achieved by maintaining a specific web page that discloses the total amounts received by donations alongside with the operational costs. ### 5. No fee or "donation" for participation or to "unlock" rewards The sustainability proposals must be designed to avoid creating a divide within the Tor network, particularly between free and paid tiers. To ensure Tor remains accessible to all: - Participation in sustainability or incentivization proposals and the acquisition of rewards must be completely free of any charges. - True incentives for network contribution should not require relay operators to incur any direct (such as product purchases) or indirect expenses (like fees). - Any system not approved officially as described in this policy by the Tor Project that forces contributors and relay operators to purchase tokens, coins, hardware, or any form of digital or physical assets as a prerequisite is strictly prohibited. ### 6. Fraud, cheating, and abuse prevention in Tor incentives - Any proposed incentivization must incorporate a design that is resilient to fraudulent activities and exploitative behavior. - This includes verification processes for operators, and transparent and auditable reward distribution methods. The proposal's author must put in place measures to prevent fraud and gaming the system. - As part of their threat model and security concerns, proposals need to include a section analyzing potential scenarios of fraud, cheating, or abuse. A mitigation plan must ensure that the incentivization system remains fair, equitable, and true to the spirit of voluntary contribution that is crucial for the Tor community. ### 7. Conflict of Interest (COI) Policy Proposals and their implementation must follow this policy of Conflict of Interest: - All individuals and entities involved in the development, promotion, or management of sustainability and incentivization proposals for the Tor relay operator community must disclose any potential conflicts of interest and disclose the lack of a conflict to the Tor Community Policy editors, Tor Project Network Health and Community Team Leads. - These conflicts could include, but are not limited to, financial gain, personal relationships, or affiliations with organizations that could benefit directly or indirectly from the proposal. The definition of financial gain, affiliation and relationship will be added to the Tor Community Policies repository as a new informative proposal. - The Tor Project Inc (TPI) employees must follow the TPI Conflict of Interest policy. - Any party found to have a conflict of interest must immediately report to the Tor Project to either resolve the conflict in a way that aligns with the standards set by the Tor Project or voluntarily withdraw from the decision making process related to that conflict. The report must be sent to the Tor Project Network Health and Community Team Leads. ### 8. Reporting scammers and avoiding risks Unfortunately, scammers and bad actors are not new to the Tor Community and probably they won't go away anytime soon. If you want to report a project using the [Tor Project trademark](https://www.torproject.org/about/trademark/), the best way to do this is to email: frontdesk(a)torproject.org. If your report is about malicious relays on the Tor network, please submit your report to bad-relays(a)lists.torproject.org. The Tor Project is committed to maintain the anonymity and privacy of those who report. Be warned that sharing suspicious content on public channels will get your post excluded and your account banned by moderators. Relay operators should exercise caution regarding the source of their funds. In cases where there is suspicion that received donations may come from an illicit or controversial source, potentially jeopardizing one's reputation, operators are strongly advised to seek counsel from a legal advisor or contact their local relay association for guidance. ### 9. Frequently Asked Questions #### Q1: I'm a relay operator, and someone wants to buy me a beer for contributing to Tor, do I really need to submit a proposal? No, donations in any form do not require a proposal. #### Q2: I'm part of a relay association and we want to raise money to run more relays, how do we know if we need to apply? If you're operating as a non-profit, you do not need to apply. Relay associations are considered part of the Tor Community. #### Q3: I'm a cryptocurrency enthusiast, with an epic DAO tokenomics that is going to moon 10x in three weeks, you want a POAP? Join my discord! Before going to moon, please submit a full proposal to us, earthlings. #### Q4: I built a hardware device that people can buy to plug in and contribute to the Tor network as a relay, do I need to apply? As long you do not use 'Tor' as part of your product name and you're following the Tor Project policies, you are not required to apply. However, meeting with the Tor Project is strongly recommended. Please note that there are other hardware projects being developed by the Tor community, for example, by Science & Design, Inc. [Pi Relay](https://pirelay.computer/). #### Q5: I'm a VPN company and I built into our app a way to contribute a snowflake proxy, should I rip that out until I figure out how to do this process? No, although Snowflake is part of the Tor network, it's different from relays as we cannot remove "bad" snowflake proxies. However, we recommend getting in touch with the Tor Project Anti-censorship Team to ensure you're following their best practices and policies. #### Q6: We are a company who makes a cryptocurrency wallet application. We've built Tor support into our app to transmit transactions over the tor network for network-level privacy protections. We get a cut of those transactions. We want to give back by running relays, but do we need to apply to do that? Depends, if your wallet users are paying a fee to run a relay, then, yes, you need to write a full proposal. If you're talking about donating profits from your business and you've declared your 'MyFamily' relays, then following the [Expectations for Relays Operators](https://community.torproject.org/policies/relays/expectations-fo… is enough. ## References * Safeguarding the Tor network: our commitment to network health and supporting relay operators (2023) https://blog.torproject.org/tor-network-community-health-update/ * Tor incentives research roundup: GoldStar, PAR, BRAIDS, LIRA, TEARS, and TorCoin (2014) https://blog.torproject.org/tor-incentives-research-roundup-goldstar-par-br… * Two incentive designs for Tor (2009) https://blog.torproject.org/two-incentive-designs-tor/ """ Thanks, Gus -- The Tor Project Community Team Lead

1 0

PSA: Rejecting bridges running 0.4.7 (EOL)
by gus 11 Jun '24

11 Jun '24

Hi, The bridge authority Serge has upgraded to tor-0.4.8.12 and it's now rejecting bridges running tor-0.4.7.x (end-of-life). Please upgrade your bridge to tor 0.4.8.x to return to the network. Bridges affected: https://metrics.torproject.org/rs.html#search/type:bridge%20version:0.4.7%20 Gus -- The Tor Project Community Team Lead

1 0

Re: [tor-relays] Directory authorities not giving weight to a relay
by smoothop＠tutanota.de 08 Jun '24

08 Jun '24

Hello! Thank you very much for your detailed response. I have been checking everything you and the others have said, and seems like my naivety was the problem all along. TLDR: Hosting (Hostiko) does shady practices and limits server bandwidth Before getting to the solution, let me enumerate a list of things my friend who I work with and I have done over the past week: Checked tor logs, hoping to find some error that told me that something was wrong with my tor setup (nothing was found!) Checked zabbix metrics, but nothing out of the ordinary (also worth to mention that this was setup after the drop in consensus weight) Tried to install vnstat from source and failed miserably, about 15 minutes into the "make install" it threw an error. I cleaned everything that was made (or so I thought) and installed it with pkg because I was too lazy to make the compilation work. Spoiler alert: I was getting tons of permission errors and similar with everything related to vnstat. I just let it be and assummed that zabbix would get me the same values that vnstat would. Updated FreeBSD to the latest version (downloading everything was rather slow, hmm...) Updated my tor relay to 0.4.8.11 Nothing worked, so as a last resort I checked the server bandwidth once more (this was already checked when I first got the server, and it was fine). Speedtest reported around 3 Megabits per second. My friend also ran iperf and we got a similar result. Anyway, I log into the customer area of the hoster and open a live chat. My message was the following: > Hello! I am having issues with my server bandwidth. I should have something close to 200 mbit but I seem to be getting 3 mbit max After a few minutes they get back to me with this response: > Your server's speed has been limited because it is being used for traffic proxying. According to our policy, we restrict VPS that are used to hide the real address or to utilize our DDoS protection. This message seemed a bit weird, mostly because I didn't really understand how did the know what I am using this server for. I am aware that there are several methods (checking the relay search, duh), but on their side I just supposed that they would see traffic from the port 443 and assume that I am hosting a website or something. Then I remembered something strange that happened around the time that the consensus weight dropped. My friend had setup an alert on every login on the system, and we got one at Thursday 0:33 (We both work, so at that time we are usually asleep already) This login stood up a lot, but not because it was a root login (we only login with our users), but because of that specific IP, 178.250.189.20. A simple lookup tells us that it's related with the hosting. The ISP is MDCloud and the organization is Hostiko. At the time we assumed that this happened because the server restarted and some service triggered the login alert. Anyway, fast forward again to today, and I checked the root user command history and this is what we found: The command history was disabled, then history was run again (I guess after whoever got into the server ran some commands) and exited. This is extremely shady. I checked every log in the system, even the system mail where apparently I get daily and weekly security digests (which is just a log of failed logins and some updates recommendations) and could not find anything in that specific timeframe, it's like it never happened and it's all in my head. Anyway, I'm not much of a confrontational person, so I just asked more about that limitation and how can it be. Unless I am missing something, their ToS has nothing against them. Their response: > We do not prohibit VPNs or Tor middle nodes, but we limit network speed once the traffic exceeds the acceptable amount for your plan. In your case, we noticed that the server was used solely for proxying and exhibited an unnaturally consistent level of traffic (almost the same 24/7), so we have limited it. Since we use more expensive DDoS protection in Germany and Poland, we are forced to take stricter measures. You can use our services in Ukraine, where we can apply more lenient policies. If this is unacceptable to you, we can also offer you a refund. We apologize for the inconvenience. They offered a refund, and even for the whole three months. I already gave them my details, hopefully they keep their word on this at least. I have backed up my relay keys, even though I'm not sure if I can trust them anymore. My next step currently would be to decide on a new hosting provider. I will also try to update the Good Bad ISP table. Thank you very much again! Regards.

1 0

Relay bandwidth issue
by kricklen＠tutanota.com 07 Jun '24

07 Jun '24

Hello everyone, i got a local relay running with v0.4.8.11 and the following configuration: ... RelayBandwidthRate 4 MBytes RelayBandwidthBurst 7 MBytes ExitPolicy reject *:* ExitRelay 0 SocksPort 0 About a month ago, the relay started to behave differently than it used to: A few hours after each restart, it didn't respect the bandwidth limits anymore, meaning it took what it could get. After a while my isp interrupts my connection, i guess because of exhaustive traffic or connections being established, not sure. This leads to the following loop: 1. The relay notices it's ip changed and starts over 2. It consumes max bandwidth after a while 3. The isp disconnects 4. Start at 1, until after enough loops the relay is broken and doesn't connect anymore I'm not sure what caused the different behaviour, i don't have a close look on when my relay gets an update. The issue is severe for me though, so any help in fixing the bandwidth limit again would be really appreciated. -- Sent with Tuta; enjoy secure & ad-free emails: https://tuta.com

2 1

Onion Services operators please enable tor PoW defense
by gus 06 Jun '24

06 Jun '24

Hi, As some of you might have noticed, we have a high load situation on the network for a couple of weeks now affecting in particular onion services (but not only them).[1] We recommend Onion Services operators to enable our Proof of Work (PoW) defense[2][3] and finetune their torrc[4]. If you're running onion services with onionbalance, though, PoW is currently not supported[5], but we're interested in hearing from you if this is a feature that we should prioritize. Thanks, Gus ps: this advice does not apply to relay operators, only to onion services operators. [1] https://status.torproject.org/issues/2024-05-14-network-performance-issues/ [2] https://blog.torproject.org/introducing-proof-of-work-defense-for-onion-ser… [3] https://community.torproject.org/onion-services/ecosystem/technology/pow/ [4] https://community.torproject.org/onion-services/advanced/dos/ [5] https://community.torproject.org/onion-services/ecosystem/technology/pow/#i… -- The Tor Project Community Team Lead

3 3

Directory authorities not giving weight to a relay
by smoothop＠tutanota.de 03 Jun '24

03 Jun '24

Greetings everyone! Almost three months ago I have set up my first node. Everything seemed to be going great at first and as documented in the tor lifecycle blog post. A few days after being set up the weight drastically dropped to around twenty. This seemed a bit odd since that same blog post doesn't mention anything about weight dropping so much, but it does about bandwidth, ao I just shrugged it off and assumed it was normal. Anyway, fast forward to today, and the weight hasn't really gotten above two hundred, it has been a month and a half I think since the weight drop, and it has been stale at a weight of between one hundred eighty and two hundred. I can't put my finger on what is exactly the problem, the relay currently has six flags: Fast, HSDir, Running, Stable, V2Dir and Valid. Shortly after the drop I have even seen the Guard flag for like a day. The server has capacity and is dedicated solely to being a relay, and the ISP is in the good providers list. The fingerprint of the node is ACC72E6D0FA76168AE1BA7F26996D191FEA7C9D8. Maybe someone in this list can give me a hand and point me in the right direction. Thank you in advance!

4 3

Tor relays Bazinga and JPsi2 to be shut down
by Random Tor Node Operator 03 Jun '24

03 Jun '24

Hi all, I have been operating the relays - Bazinga B198C0B4B8C551F174FBB841A172616E3DB3124D - JPsi2 F6EC46933CE8D4FAD5CCDAA8B1C5A377685FC521 for about 10 years. The hosting provider stops providing their current service and their successor services are not Tor-friendly anymore. Hence, these relays will be shut down by June 2 2024. My third relay - SafeAndEffective A508096AA0C899F4E6ECD1D9C35037B89008BCBA is unaffected.

2 1

Warn_TorBTCMoon
by tor 27 May '24

27 May '24

Nickname TorBTCMoon ContactInfo torsafe777(a)gmail.com Your computer is too slow to handle this many circuit creation requests! Please coconsider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit CPU 100% How to fix?

2 1

We need to talk about the latest DDoS affecting the Tor network
by koizoi 25 May '24

25 May '24

For several weeks now, users have been complaining (see https://www.reddit.com/r/TOR/comments/1cnmsdz/tor_extremely_slow_lately/, https://forum.torproject.org/t/is-there-currently-a-major-ddos-affecting-th…, etc) about degraded performance (slow speeds, timeouts) when using Tor, both to access v3 onion sites and clearnet websites. In my personal experience, most v3 onion services are responding so slowly that they're completely unusable. it turns out that's it not just people's imaginations, looking at charts on metrics.torproject.org, it can be seen that the time to complete a 5MiB request over Tor has increased substantially (https://ibb.co/tp1CHdh) All of this is very reminiscent of the large scale DDoS that affected Tor relay nodes in 2022-2023. Tor relay operators have reported "attacks" on their relays, but there haven't been many details about what kind of attacks are taking place, other than some people saying that they have been TCP SYN flooded. But (to me, anyway) SYN flooding doesn't really make a lot of sense as there are so many Tor relay nodes that would need to be attacked, (and misconfigured to allow a SYN flood attack to work), and even if it were a SYN flood, that would cause different behavior than what users have been seeing (preventing connections to the Tor network rather than slowing them down). I understand that DDoS attacks on the Tor network might be kind of a touchy subject, but it would be good if we could get some information from the project leadership as to what's going on, what is being done about it, and what Tor relay operators can do to help prevent attacks like these from happening. Thanks Sent with [Proton Mail](https://proton.me/) secure email.

2 1

Next Tor relay operators meetup - May 11, 2024 at 19 UTC
by gus 14 May '24

14 May '24

Hi, Please save the date: the next Tor Relay Operator will happen Saturday, May 11 at 19UTC! We're still working on the agenda for this meetup, however feel free to add your topics directly to this ticket or just reply to the mailing list: https://gitlab.torproject.org/tpo/community/relays/-/issues/92 Meetup details - Room link: https://tor.meet.coop/gus-og0-x74-dzn - When: May 11, 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. I'll send soon the last meetup notes to the list. Gus -- The Tor Project Community Team Lead

2 3

disable conflux on exit relay?
by applied-privacy.net 14 May '24

14 May '24

Hello, conflux appears to be the primary source of bugs and crashes for us in the past few months and there have been numerous issues related to it on gitlab. from the tor manual page: ConfluxEnabled 0|1|auto If this option is set to 1, general purpose traffic will use Conflux which is traffic splitting among multiple legs (circuits). Onion services are not supported at the moment. Default value is set to "auto" meaning the consensus is used to decide unless set. (Default: auto) will ConfluxEnabled 0 disable it for tor acting as a client only or for relays as well? thanks! applied-privacy.net

4 7

Updating tor issue
by Keifer Bly 13 May '24

13 May '24

https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36… Hi, so for my relay at the address above, when trying to update tor, suddenly getting the "updating from such a respiratory can't be done securly" message. Odd as this just suddenly started happening. Here is my sources file. What is the correct format for adding tor as a trusted source? Thanks. deb-src http://deb.debian.org/debian buster main ## Major bug fix updates produced after the final release of the ## distribution. deb http://security.debian.org/ buster/updates main deb-src http://security.debian.org/ buster/updates main ## Uncomment the following two lines to add software from the 'backports' ## repository. ## ## N.B. software from this repository may not have been tested as ## extensively as that contained in the main release, although it includes ## newer versions of some applications which may provide useful features. deb http://deb.debian.org/debian buster-backports main deb-src http://deb.debian.org/debian buster-backports main deb [trusted=yes] https://deb.torproject.org/torproject.org buster main --Keifer

6 13

response to zimmer family hitting max descriptor size
by code9n＠pm.me 07 May '24

07 May '24

Hi, re. # Questions & Answers * Q: zimmer family hitting max descriptor size https://gitlab.torproject.org/tpo/core/tor/-/issues/40837 Any news on a possible solution to this ongoing issue? tl;dr: more powerful relays rather than large numbers of them. *Please note I have very little idea what I'm talking about here and there's probably something I don't know about or just don't understand. If a family has a very large number of exit relays but the capacity of each one is not that great couldn't they just spend the same money on making existing relays more powerful rather than having more of them? If we're using VPSs then the limits applicable to single cores don't seem to apply the way they do to physical servers. I run a single non-exit relay but I get more traffic through it by having more RAM and multiple vCPUs. The VPS seems to act like it has one large, powerful core rather than the 5 smaller one's it 'actually' has. So if 'descriptors' refer to the number of relays not their capacity wouldn't this work? Side note: to get more bang for your buck you can ask your VPS provider to swap some storage for more vCPUs, that's what I did and it certainly seems to allow me to run more traffic through my one relay. It doesn't need that much storage anyway. So you get the same amount of traffic through fewer, larger relays. cheers,

1 0

Tor Relay Operator Meetup - Saturday, April 13, 2024 at 19 UTC
by gus 07 May '24

07 May '24

Hello, The Tor Relay Operator will happen this Saturday, April 13 at 19UTC! ## Agenda - Announcements: - New Network Health Team lead - 0.4.7 EOL removal - Relay Operator census - Elections 2024: previous (March) / next round (April) - Q&A - Please feel free to add other topics here: https://pad.riseup.net/p/tor-relay-april-meetup-keep ## Meetup details - Room link: https://tor.meet.coop/gus-og0-x74-dzn - When: April 13, 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

1 2

Ansible for Tor Network Webtunnel Bridges
by Jacobo Nájera 04 May '24

04 May '24

Hi, Share this Ansible role for Webtunnel, with which you can install, configure, and operate Tor network Webtunnel bridges. Currently, it supports installing bridges on Debian, with support for other operating systems coming soon. Repository with the Ansible role for Webtunnel https://github.com/nvjacobo/webtunnel In the Ansible Galaxy repository https://galaxy.ansible.com/nvjacobo/webtunnel A small guide to use the role https://acuare.la/en/ansible-webtunnel-bridges-tor-network/ Feedback are welcome! Thanks, Jacobo

2 3

Is the C tor client DoSStreamCreation aware?
by tor_appliedprivacy.net 28 Apr '24

28 Apr '24

Hello, is the upstream C tor client implementation (in git main) aware of the DoSStreamCreation consensus parameters and defaults thresholds and respects them to avoid triggering these exit relay defenses? If that is currently not the case yet, would it make sense to make it aware so it will never try to create streams at a higher rate? Even if it would be aware already, it would not self limit currently because the current consensus does not enable DoSStreamCreationEnabled. thanks! tor(a)appliedprivacy.net

1 0

Webtunnel type bridge Tor Metrics
by Dionysios K. 25 Apr '24

25 Apr '24

Hello everyone, I recently switched from using obfs4 to Webtunnel from my bridge. Since the configuration change, the metrics website shows it as offline. The downtime displayed on the website is also odd as it shows a random time each time I visit, such as "1 hour 14 minutes and 10 seconds" or "2 hours 23 minutes and 30 seconds." However, the bridge is online. I am wondering if this is the correct behavior for the Webtunnel protocol.

4 5

Re: [tor-relays] Webtunnel type bridge Tor Metrics
by Dionysios K. 25 Apr '24

25 Apr '24

Hey Hiro, The issue was solved for a few hours, it was the first time since I switched to webtunnel I saw my bridge online, but now it's again marked as offline. It's the same issue again. ---------------------------------------- Apr 24, 2024 8:02:02 PM Hiro <hiro(a)torproject.org>: > Dionysios, all, > > This was an issue with rdsys and documents that weren't being synced to the vm where collector.torproject.org lives. > > For details: > > https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/199 > > It should be solved now. > > Talk soon, > > -hiro > > On 4/22/24 22:13, Hiro wrote: >> Hey, >> >> On 4/20/24 17:40, Dionysios K. via tor-relays wrote: >>> Hello everyone, >>> >>> I recently switched from using obfs4 to Webtunnel from my bridge. >>> >>> Since the configuration change, the metrics website shows it as offline. >>> >>> The downtime displayed on the website is also odd as it shows a random time each time I visit, such as "1 hour 14 minutes and 10 seconds" or "2 hours 23 minutes and 30 seconds." >>> >>> However, the bridge is online. >>> >>> I am wondering if this is the correct behavior for the Webtunnel protocol. >> >> The way the metrics website "decides" if a bridge is online is based on both the results of tests from the bridge authority and bridgestrap. If the bridge is working and receiving traffic, the reason why I can think it is marked as offline is that some of those tests is failing or we are failing to process the data correctly. >> >> It could also be that something is a bit off with the bridge configuration since you changed from obfs4 to webtunnel. You could start your investigation by looking at the logs on the machine, then you could check what the bridgestrap stats say about your bridge (https://collector.torproject.org/recent/bridgestrap/) and finally check the latest status (https://collector.torproject.org/recent/bridge-descriptors/statuses/) >> >> Let me know if this helps you. I could also check the bridge myself, you could open an issue on gitlab under the relay-search project (https://gitlab.torproject.org/tpo/network-health/metrics/relay-search) or you can send me a private message (email or irc) with the hashed fingerprint and logs. >> >> Cheers, >> >> -hiro >> >> >>> >>> _______________________________________________ >>> tor-relays mailing list >>> tor-relays(a)lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

DoSStreamCreation consensus parameters
by tor_appliedprivacy.net 25 Apr '24

25 Apr '24

Hello, today we saw yet another outbound flooding affecting our exit relays and we were eager to see the effect of https://gitlab.torproject.org/tpo/core/tor/-/issues/40736 but we did not see any and according to metric tor_relay_dos_total{type="stream_rejected"} the protection did not trigger. What are the consensus parameter names for these settings so we can check there current consensus values? > DoSStreamCreationEnabled 0|1|auto > Enable the stream DoS mitigation. If set to 1 (enabled), tor will > apply rate limit on the creation of new streams and dns requests > per circuit. "auto" means use the consensus parameter. If not > defined in the consensus, the value is 0. (Default: auto) > > DoSStreamCreationDefenseType NUM > This is the type of defense applied to a detected circuit or stream > for the stream mitigation. The possible values are: > > 1: No defense. > > 2: Reject the stream or resolve request. > > 3: Close the circuit creating too many streams. > > "0" means use the consensus parameter. If not defined in the > consensus, the value is 2. (Default: 0) > > DoSStreamCreationRate NUM > The allowed rate of stream creation from a single circuit per > second. Coupled with the burst (see below), if the limit is > reached, actions can be taken against the stream or circuit > (DoSStreamCreationDefenseType). If not defined or set to 0, it is > controlled by a consensus parameter. If not defined in the > consensus, the value is 100. (Default: 0) > > DoSStreamCreationBurst NUM > The allowed burst of stream creation from a circuit per second. See > the DoSStreamCreationRate for more details on this detection. If > not defined or set to 0, it is controlled by a consensus parameter. > If not defined in the consensus, the value is 300. (Default: 0) thanks! tor(a)appliedprivacy.net

1 1

I need a new VPS provider
by Landon 22 Apr '24

22 Apr '24

Hello, I am currently using gcore.com as my VPS hosting provider. I have been running a Tor bridge with them for several years now. I am supposed to be getting 200 Mbps unmetered bandwidth. However, in the past six months, my bandwidth usage has been declining a lot. It seems like they might be throttling my server. I was getting over 2000 connected clients and now I'm down to less than 600. "iftop" shows me about 30 to 60 Mbps bandwidth usage during any time of the day. Take a look... https://metrics.torproject.org/rs.html#details/4A0B065DB3CF807C6910DFEF6D9C… So, I am trying to find a Tor friendly VPS provider that offers 1 Gbps unmetered bandwidth. I found my current provider in an article describing Tor friendly providers, but I cannot locate that link. I am currently paying about 15 Euros a month for a server with 2 cores, 4 GB RAM and 100 GB SSD. I would like to pay about the same for my new service. In my search, I have found some better providers, but they don't seem to be Tor friendly. Do you have a good provider that you really like that offers inexpensive VPS? I would prefer one located in the USA if possible, but I guess it doesn't matter if the bandwidth is good. Landon

5 5

tor_bug_reached_count increase
by tor＠appliedprivacy.net 20 Apr '24

20 Apr '24

Hello, the new metricsport counter shows that some specific tor relays (2 out of 50) have a significant tor_bug_reached_count rate (around 8 per second). Do you see similar? You have to run on git main or nightly builds to see that metric. best regards, tor(a)appliedprivacy.net

3 2

issues with tor-nightly-main repo
by applied-privacy.net 20 Apr '24

20 Apr '24

Hello, the repo failed to get new updates after Version: 0.4.9.0-alpha-dev-20240415T020400Z-1~d12.bookworm+1 but we would be eager to test changes that got into main in the last few days. https://deb.torproject.org/torproject.org/dists/tor-nightly-main-bookworm/m… aarch64 build fails. Deploy job is skipped: https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/529032 https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/528021 https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/528040 best regards, applied-privacy.net

4 3

Request for Feedback on Relay Node Update Management
by Alessandro Greco 19 Apr '24

19 Apr '24

Dear Tor-Relays Mailing List Members, I hope this email finds you well. I'm reaching out to share some observations and pose some questions regarding the management of relay node updates, particularly concerning their impact on stability and security of the service provided. Recently, I've noticed an interesting pattern with my relay node (ID: 47B72187844C00AA5D524415E52E3BE81E63056B [1]). I've followed TorProject's recommendations [2] and configured automatic updates, which has led to frequent restarts of the node to keep the Tor software up-to-date. While this practice ensures high security by keeping the software updated, it seems to compromise the stability of the node itself. The Uptime value of my node has remained at a maximum of a few hours. This situation has prompted me to reflect on what might be the best strategy to adopt. On one hand, frequent updates ensure optimal security, while on the other hand, continuous restarts may affect the user experience for those relying on the node's stability for their Tor activities. As such, I'd like to pose some questions to the community to gather feedback and assess best practices: 1. In your opinion, is it preferable to maintain automatic updates to ensure maximum security, even if frequent restarts may compromise the node's stability? 2. Or would it be more sensible to adjust the update frequency, perhaps performing them once or twice a week, to ensure greater stability of the node without excessively compromising security? 3. Have you had similar experiences with your relay nodes? How have you addressed this challenge and what were the outcomes? Thank you in advance for your time and cooperation. Best regards, Aleff. [1] https://metrics.torproject.org/rs.html#details/47B72187844C00AA5D524415E52E… [2] https://community.torproject.org/relay/setup/guard/debian-ubuntu/updates/ --- 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)

6 11

issues with tor rpm : anyone sees what I am doing wrong ?
by Carlos 16 Apr '24

16 Apr '24

Hi, lacking competence or support to build bridges under DEBIAN 12, I tried FEDORA and this feeeeeels cool. Yep yet this worry some message : Errors during downloading metadata for repository 'tor': - Status code: 404 for https://rpm.torproject.org/fedora/repodata/repomd.xml (IP: 2620:7:6002:0:466:39ff:fe7f:1826) Error: Failed to download metadata for repo 'tor': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried here is my bash script before the error that I find absolutely fine... kindly prove me wrong, please. Carlos. (would PGP encryption make sense when sending these types of emails to tor-relays(a)lists.torproject.org ? can't see the mailing list PGP publicly) dnf update dnf install dnf-automatic -y systemctl enable --now dnf-automatic-install.timer echo "[tor]" > /etc/yum.repos.d/Tor.repo echo "name=Tor for Fedora $releasever - $basearch" >> /etc/yum.repos.d/Tor.repo echo "baseurl=https://rpm.torproject.org/fedora/$releasever/$basearch" >> /etc/yum.repos.d/Tor.repo echo "enabled=1" >> /etc/yum.repos.d/Tor.repo echo "gpgcheck=1" >> /etc/yum.repos.d/Tor.repo echo "gpgkey=https://rpm.torproject.org/fedora/public_gpg.key" >> /etc/yum.repos.d/Tor.repo echo "cost=100" >> /etc/yum.repos.d/Tor.repo dnf install tor -y dnf install obfs4 -y -- PGP updated every second week : please actualize our communication every time.

3 2

Node 6E02FDEA15122A492A799A58C4C11D02637B145A is marked as down, but logs display no issues
by 0N ODV 09 Apr '24

09 Apr '24

Hi all, our node sacco.osservatorionessuno.org[1] has been marked down for more than a couple of days. It is at the latest version from Tor's Debian repository and I tried to restart both the service and the server. The process is running, and the 9001 and 9030 ports are open and succesfully reachable from the outside. The notice log I temporarily enabled to look for the issue apparently does not show any warning signs. Here is an anonymized output of the log: [notice] Tor 0.4.8.10 opening new log file. [notice] We compiled with OpenSSL XXX and we are running with OpenSSL XXX. These two versions should be binary compatible. [notice] Tor 0.4.8.10 running on Linux with Libevent XXX, OpenSSL XXX, Zlib XXX, Liblzma XXX, Libzstd XXX and Glibc XXX as libc. [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/ [notice] Read configuration file "/etc/tor/torrc". [notice] Based on detected system memory, MaxMemInQueues is set to 720 MB. You can override this by setting MaxMemInQueues by hand. [notice] Opening Socks listener on 127.0.0.1:9050 [notice] Opened Socks listener connection (ready) on 127.0.0.1:9050 [notice] Opening OR listener on XXX:9001 [notice] Opened OR listener connection (ready) on XXX:9001 [notice] Opening OR listener on [XXX]:9001 [notice] Opened OR listener connection (ready) on [XXX]:9001 [notice] Opening Directory listener on XXX:9030 [notice] Opened Directory listener connection (ready) on XXX:9030 [notice] Opening Directory listener on [XXX]:9030 [notice] Opened Directory listener connection (ready) on [XXX]:9030 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. [notice] Your Tor server's identity key fingerprint is 'sacco XXX' [notice] Your Tor server's identity key ed25519 fingerprint is 'sacco XXX' [notice] Bootstrapped 0% (starting): Starting [notice] Starting with guard context "default" [notice] Bootstrapped 5% (conn): Connecting to a relay [notice] Unable to find IPv4 address for ORPort 9001. You might want to specify IPv6Only to it or set an explicit address or set Address. [notice] Bootstrapped 10% (conn_done): Connected to a relay [notice] Bootstrapped 14% (handshake): Handshaking with a relay [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit [notice] External address seen and suggested by a directory authority: XXX [notice] Bootstrapped 100% (done): Done [notice] Now checking whether IPv4 ORPort XXX:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) [notice] Now checking whether IPv6 ORPort [XXX]:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) [notice] Self-testing indicates your ORPort XXX:9001 is reachable from the outside. Excellent. [notice] Performing bandwidth self-test...done. [notice] Self-testing indicates your ORPort [XXX]:9001 is reachable from the outside. Excellent. Publishing server descriptor. [notice] Heartbeat: It seems like we are not in the cached consensus. [notice] Heartbeat: Tor's uptime is XX hours, with XX circuits open. I've sent XX and received XX. I've received XXX connections on IPv4 and XXX on IPv6. I've made XXX connections with IPv4 and XXX with IPv6. [notice] While bootstrapping, fetched this many bytes: XXX (microdescriptor fetch) [notice] While not bootstrapping, fetched this many bytes: XXX (server descriptor fetch); XXX (server descriptor upload); XXX (consensus network-status fetch); XXX (microdescriptor fetch) [notice] Circuit handshake stats since last time: X/X TAP, X/X NTor. [notice] Since startup we initiated XXX and received XXX v1 connections; initiated 0 and received 0 v2 connections; initiated XXX and received XXX v3 connections; initiated XXX and received XXX v4 connections; initiated XXX and received XXX v5 connections. [notice] Heartbeat: DoS mitigation since startup: 0 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 0 marked addresses for max queue, 0 same address concurrent connections rejected, 0 connections rejected, 0 single hop clients refused, 0 INTRODUCE2 rejected. [notice] Your network connection speed appears to have changed. Resetting timeout to XXXms after XXX timeouts and XXX buildtimes. We would appreciate any hint on how to proceed to debug the issue in order to keep the server useful. Thank you Giuio [1] - https://metrics.torproject.org/rs.html#details/6E02FDEA15122A492A799A58C4C1…

3 3

Re: [tor-relays] R: Re: Request for Feedback on Relay Node Update Management
by denny.obreham＠a-n-o-n-y-m-e.net 04 Apr '24

04 Apr '24

You should tweak your web server as presented in this section: https://github.com/Enkidu-6/tor-ddos?tab=readme-ov-file#first-step-prep aring-your-system-for-high-number-of-connections This would most likely solve Out-Of-Memory problems I suspect you are experiencing. Denny On 04/02/2024 10:06 AM Alessandro Greco via tor-relays wrote .. My computer has: - 1 vCore CPU - 1 GB RAM - Maximum bandwidth: 1 GB/s So if I understand correctly, the problem should not be at the hardware level, right? Il mar, apr 2, 2024 alle 12:14, Frank LÃ½ via tor-relays <[1]tor-relays(a)lists.torproject.org> ha scritto: Hello Aleff, That is up to you. I strongly suspect that the hardware is the bottleneck, but detailed specifications are required in order to determine a conclusion. Tor is currently bounded by single-thread CPU performance, with a minimum recommendation of 1 GB of RAM for non-exit relays faster than 40 Mbit/s. If your hardware does not meet these RAM requirements, upgrade it, then adjust the relay bandwidth rate limit as necessary. Frank Mar 27, 2024, 7:00 AM by tor-relays(a)lists.torproject.org: > I want to thank you for all the support replies you sent in response to my previous communication. I have carefully read through all your insights and appreciate your efforts in trying to find a solution to the issue. > > After thorough consideration of the matter, I have concluded that the problem may not be due to configuration errors in the automatic updates, as initially speculated. Rather, it seems that the issue could be hardware-related, with my VPS computer potentially unable to handle a certain amount of traffic. > > It's worth noting that there are no bandwidth issues, and the connection speed is high. However, I have set a RelayBandwidthRate limit of 250 Mbits. Interestingly, despite this configuration, the Tor Metrics site detects a speed of approximately 10/13 MBytes, equivalent to about 90/110 Mbits. This led me to speculate that the machine might experience an overload of operations or connections, causing it to crash temporarily. As a result, at the time of restart, Tor Statistics records the maximum speed reached up to that point (without ever reaching the set limit). Subsequently, following this theory, the Tor service restarts automatically without causing any anomalies in the service. > > To address this situation, I have decided to reduce the RelayBandwidthRate limit from 250 Mbits to 100 Mbits, which falls within the minimum limits proposed by torproject. If this is the case, however, it is also true that it would be best to impose an upper limit of 80% when considering the bandwidth magnitude involving the crash event as the maximum point. I honestly don't know how I would be able to verify this and acquire this kind of data, probably doing trial and error is the way. Perhaps the ideal would be to lower the maximum bandwidth further to verify for sure that this is what it is? > > Currently, I am closely monitoring the situation to assess whether this modification has a positive impact on the issue. > > I will keep you updated on any progress, and I thank you once again for your support and understanding. > > 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) > > martedÃ¬ 26 marzo 2024 11:21, torrelay.9puwh--- via tor-relays ha scritto: > >> Hi Alessandro, >> >> It's good to hear from you. I have a relay in a somewhat similar situation[1], although I've only just clocked it. If you're using Debian or one of its derivatives, then you can configure the unattended-upgrades package to perform a restart at a specific time if required. This means that your relay won't restart every time an upgrade is required, but will keep itself up to date. I think configuring a time for a daily restart (if upgrade required) would be a fairly good balance between stability and reliability. >> >> See what other people say or from your own experience, as Tor circuits are generally quite resilient and as long as you aren't a guard node I believe connections won't die because your relay is restarting. >> >> I would also note that Tor recommends [2] an uptime or 24/7 is nice, but not required and that restarts to the daemon or node are fine. Because of this, it might not be worth worrying too much about this issue. >> >> I hope you find some of this useful, >> Seth >> >> >> >> [1] https://metrics.torproject.org/rs.html#details/5FEB80D4DCC63180CB4D8 7C1222177BB099E55AE >> [2] https://community.torproject.org/relay/relays-requirements/ >> -------- Original Message -------- >> On 26/03/2024 08:54, Alessandro Greco via tor-relays tor-relays(a)lists.torproject.org wrote: >> >> > Dear Tor-Relays Mailing List Members, >> > >> >> > I hope this email finds you well. I'm reaching out to share some observations and pose some questions regarding the management of relay node updates, particularly concerning their impact on stability and security of the service provided. >> > >> >> > Recently, I've noticed an interesting pattern with my relay node (ID: 47B72187844C00AA5D524415E52E3BE81E63056B [1]). I've followed TorProject's recommendations [2] and configured automatic updates, which has led to frequent restarts of the node to keep the Tor software up-to-date. While this practice ensures high security by keeping the software updated, it seems to compromise the stability of the node itself. The Uptime value of my node has remained at a maximum of a few hours. >> > >> >> > This situation has prompted me to reflect on what might be the best strategy to adopt. On one hand, frequent updates ensure optimal security, while on the other hand, continuous restarts may affect the user experience for those relying on the node's stability for their Tor activities. >> > >> >> > As such, I'd like to pose some questions to the community to gather feedback and assess best practices: >> > >> >> > 1. In your opinion, is it preferable to maintain automatic updates to ensure maximum security, even if frequent restarts may compromise the node's stability? >> > 2. Or would it be more sensible to adjust the update frequency, perhaps performing them once or twice a week, to ensure greater stability of the node without excessively compromising security? >> > 3. Have you had similar experiences with your relay nodes? How have you addressed this challenge and what were the outcomes? >> > >> >> > Thank you in advance for your time and cooperation. >> > >> >> > Best regards, >> > Aleff. >> > >> >> > [1] https://metrics.torproject.org/rs.html#details/47B72187844C00AA5D524 415E52E3BE81E63056B >> > [2] https://community.torproject.org/relay/setup/guard/debian-ubuntu/upd ates/ >> > >> >> > --- >> > >> >> > 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)_______________________________________________ >> > tor-relays mailing list >> > tor-relays(a)lists.torproject.org >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays 1. file:///tmp/.webmin/reply_mail.cgi?new=1&to=Il

2 1

User advisory to check for xz-utils backdoor
by pasture_clubbed242＠simplelogin.com 02 Apr '24

02 Apr '24

Greetings, I do not normally use mailing lists such as this one to inform subscribers of security notices, but this issue is extreme enough where it may benefit the anonymity of Tor users if relay operators are aware of it sooner. The near-universally used 'xz' compression library has been found to contain a backdoor in certain code branches. This backdoor has made it into some systems such as Debian Sid. Details regarding this backdoor are available here. https://www.openwall.com/lists/oss-security/2024/03/29/4 It is suspected that if your OpenSSH server links to the xz library, which Debian appears to do so, then this backdoor is remotely exploitable. If your OpenSSH server does not link to this library, then your system still contains many processes that run xz actions as the root user, some input of which may be less than trusted. For those needing a patch, I recommend you research your distribution's security advisory page for further information. References: Debian Sid Advisory: https://security-tracker.debian.org/tracker/CVE-2024-3094

2 1

Backdoor in upstream xz/liblzma leading to ssh server compromise
by hello＠relaymagic.org 02 Apr '24

02 Apr '24

Just wanted to bring this to everyone’s attention if you hadn’t seen it already. Developer discovered a backdoor in xz-utils https://www.openwall.com/lists/oss-security/2024/03/29/4 -- Sent from Canary (https://canarymail.io)

2 1

Tor relay operator research
by Ana Custura 29 Mar '24

29 Mar '24

Dear operators, We're conducting a study to understand relay operator motivations and needs, funded by OTF. We've already interviewed several of you and got feedback relating to community matters. Based on that feedback, we've put together a comprehensive survey: English: https://survey.torproject.org/index.php/751125?lang=en Spanish: https://survey.torproject.org/index.php/751125?lang=es If you have about 30 minutes to spare and fill this in, it would be much appreciated! Your responses are valuable and will be used by the Tor project to understand the needs of the community, and how you feel about some controversial Tor-related issues. The survey is anonymous. Cheers Ana PS: to find out more about the project, see https://www.opentech.fund/projects-we-support/supported-projects/the-tor-pr…

1 0