- tor-relays - lists.torproject.org

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 12 Jun '24

12 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 13 May '24

13 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 06 May '24

06 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 03 May '24

03 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 24 Apr '24

24 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 19 Apr '24

19 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