October 2025 - tor-relays - lists.torproject.org

relayor v25.1.0 is released
by nusenu 14 Oct '25

14 Oct '25

Hi, relayor v25.1.0 is released. https://github.com/nusenu/ansible-relayor/releases/tag/v25.1.0 relayor is an ansible role that helps you with running tor relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor-relay-ope… Changes: * Debian 13 is supported (please upgrade your Debian 12 relays because we plan to remove support for Debian 12 / Debian oldstable) * FreeBSD 14.3 is supported * increase minimal required ansible version from 2.16.14 to 2.18.1 **Note on upgrading from previous relayor versions** when managing Debian/Ubuntu relays A manual step is required when upgrading from previous versions on Debian/Ubuntu relays. To avoid conflicting apt sources make sure to move this file on your Debian/Ubuntu relays directly before running ansible-relayor v25.1.0 for the first time. You can use this command to move the file into your home: sudo mv -i /etc/apt/sources.list.d/deb_torproject_org_torproject_org.list ~ Make sure you did not edit the content of this file before. kind regards, nusenu -- https://nusenu.github.io

1 0

[Proposal] Tor exit lifecycle
by gus 14 Oct '25

14 Oct '25

Dear relay operators, We've drafted a new proposal for the relay operator community. The proposal introduces a lifecycle for Tor exit relays, inspired by the existing lifecycle used for Guard and HSDir flags. The main goal is to make it harder for attackers to quickly deploy malicious exit relays. Your feedback is welcome! You can read and comment on it here: https://gitlab.torproject.org/tpo/community/policies/-/issues/32. Alternatively, you can read the full text below. Gus ``` Filename: 102-tor-exit-lifecycle.md Title: Tor Exit lifecycle Author: Gus - gus at torproject.org, GeKo - gk at torproject.org, Hiro - hiro at torproject.org Created: 2025-10-14 Status: Draft ``` ## Overview Tor exit relays are maintained by volunteers and used to leave the Tor network and access websites and other online services. This proposal introduces a lifecycle for Tor exit relays, inspired by the lifecycle already used for non-exit relays to acquire particular flags, such as the Guard[1] and HSDir[2] flags. The main goal of this proposal is to make it harder for attackers to quickly deploy malicious exit relays and exploit Tor users. The proposed lifecycle adds a staging phase for new relays configured as exit relays. This is a period during which those relays are only functioning as non-exit relays. Afterwards, they become eligible for the Exit flag and can then be used as exit relays as intended. This exit relay lifecycle should raise the operational costs for malicious actors, enable earlier detection of bad relays[3], and provide more protection against Sybil attacks. ## Motivation Currently, because Tor is an open and public network, any relay operator can set up a new exit relay and, after a brief warm-up period, begin handling real user traffic. Malicious actors have exploited this openness to launch man-in-the-middle (MITM)[4][5] attacks, leading to a continuous "whack-a-mole" situation for the Network Health Team and the Directory Authorities: while attackers can often be blocked before causing major harm, significant human resources are required to keep up with them. As a small non-profit, it is essential for the Tor Project to focus its limited resources on mission-critical tasks. By implementing mitigations that force adversaries to invest more time and effort or make their attacks faster and easier to detect, we create a more favorable scenario for the Tor Project and its users. To help with that, a staged lifecycle for exit relays will: - Slow down the deployment speed of malicious exit relays as they will need to go through a staging phase. - Give time for analysis and automatic or proactive scanning before an exit relay sees and can exploit any outgoing user traffic. ## Proposal New relays configured as exit relays must complete a staging phase of 4 days (configurable) before becoming eligible for the Exit flag. The staging phase should be long enough to deter opportunistic abuse, but short enough not to discourage legitimate relay operators. ### Security implications The proposed change does not harm user anonymity or security. By reducing the number of new, untrusted exit relays on the Tor network, it improves safety for Tor users and disincentivizes short-lived "throwaway" malicious exit relays. ## Implementation considerations The exit relay lifecycle could be implemented with the help of Tor configuration options or consensus parameters, so that Directory Authorities can tune the staging length without a tor release, or disable the feature temporarily in unusual capacity situations. The exact code and format details will be specified in a follow-up torspec proposal (and then implemented in tor/arti). Note that the technical implementation may have slight changes to this proposal. ### Participation and Communication Once the exit lifecycle is implemented in a torspec proposal, a communication strategy will take place to inform and support relay operators. This strategy may include, but is not limited to, the following actions: - Update the [Tor Relay Operator documentation](https://community.torproject.org/relay) to include an explanation of the new exit relay lifecycle. - Display a banner on Tor Metrics Relay Search for new exit relays, directing users to the exit lifecycle proposal or relevant documentation. - Inform the relay operator community on their communication channels such as the tor-relays mailing list, blog post, and the Tor Forum. - Document new behavior resulted of the exit lifecycle, for example, if an exit relay drops of the consensus for a period, they will lose their exit flag and will need to restart the lifecycle described on this document. For the implementation discussion, see: https://gitlab.torproject.org/tpo/network-health/team/-/issues/220. ## Notes [1] Tor Guard specification: https://spec.torproject.org/guard-spec/index.html \ [2] HSDIR https://spec.torproject.org/tor-spec/subprotocol-versioning.html?highlight=… \ [3] Criteria for bad relays: https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Criteria-for-… \ [4] Also known as a monster-in-the-middle, machine-in-the-middle, meddler-in-the-middle, manipulator-in-the-middle, person-in-the-middle (PITM), or adversary-in-the-middle (AITM) attack. \ [5] https://blog.torproject.org/bad-exit-relays-may-june-2020/ -- The Tor Project Community Team Lead

1 0

Bug: conflux_util.h:24
by abir 13 Oct '25

13 Oct '25

Oct 12 21:24:47.000 [warn] tor_bug_occurred_: Bug: conflux_util.h:24: CIRCUIT_IS_CONFLUX: Non-fatal assertion circ->purpose == CIRCUIT_PURPOSE_CONFLUX_UNLINKED failed. (on Tor 0.4.9.3-alpha 1ee22f8f9a98719d) Oct 12 21:24:47.000 [warn] Bug: Tor 0.4.9.3-alpha (git-1ee22f8f9a98719d): Non-fatal assertion circ->purpose == CIRCUIT_PURPOSE_CONFLUX_UNLINKED failed in CIRCUIT_IS_CONFLUX at conflux_util.h:24. (Stack trace not available) (on Tor 0.4.9.3-alpha 1ee22f8f9a98719d)

2 1

shutting down a relay with less interruption for maintenance
by Marco Moock 13 Oct '25

13 Oct '25

Hello! I would like to ask what the preferred way is to shut down a relay gracefully in case of maintenance downtime to avoid interrupted connections. The shutdown process might take a while. -- Gruß Marco Send unsolicited bulk mail to 1760260473muell(a)stinkedores.dorfdsl.de

2 1

Relay not ramping up as expected
by tor＠busybear.se 12 Oct '25

12 Oct '25

Hello. My exit 7BE9E2EF2BB41BB662D9A3CD68289B9E3DBF8A08 WYSWYG has kinda frozen at the current status, although formerly being both guard, stable and advertising towards 60 MB output on a 1Gb fibre. My provider, Bahnhof, has no problem with Tor, even though my exit been investigated by the police as involved in the biggest leak in Sweden without consequences for me. Uptime should be enough by now for at least a stable flag. Speedtest on my IP says upwards 950 Mb up\down. My torrc is simple: ORPort 65532 DirPort 65533 #ClientPreferIPv6ORPort Nickname WYSWYG Contactinfo <tor AT busybear DOT se> ExitRelay 1 Log notice file /home/*/torlog SafeLogging 1 ProtocolWarnings 1 RunAsDaemon 1 ControlPort 9051 CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /home/*/control_auth_cookie #GeoIPFile /home/*/TorBrowser/Data/Tor/geoip IPv6Exit 0 ConnDirectionStatistics 1 ExtraInfoStatistics 1 Any suggestions? Logs provided on request. \Bamse

1 0

My Tor Relay Is Slower Than Expected (Already Did Basic Debugging)
by eviljoel 09 Oct '25

09 Oct '25

Greetings, I'm running the "chinstrap" Tor relay and am seeing high variability on the bandwidth graph here: https://metrics.torproject.org/rs.html#details/F01C3861418540248EAEC724038C… I've run Tor relay's before and don't remember seeing this much variability. I've setup my relay as a bridge and can consistently pull 300k from the relay but the bandwidth graph is showing far less than that on average. I was hoping someone could take a look and tell me if anything looks wrong. Also, if there is a problem, what I can do to fix it? The relay is configured for 414.25 KBytes per second with a burst rate of four times that amount. Thank you, eviljoel -- eviljoel's PGP fingerprint: A2BE 2D12 24D1 67CA 8830 DDE7 DFB3 676B 196D 6430

1 0

Running a Snowflake bridge on Debain
by Keifer Bly 05 Oct '25

05 Oct '25

Hi, So I am running a snowflake bridge, and here is the output after it running for a few days. Wondering, on my system, as there is no torrc configuration, is there a port that needs to be forwarded? How can I check if the bridge is reachable? Is the app from here: https://snowflake.torproject.org/ Thanks all. --Keifer

2 1

bridge relay marked as down but I can manually connect to it
by Eritque arcus 04 Oct '25

04 Oct '25

Hi, I don't know why but my bridge relay marked as down but I can connect to it with my Tor browser. Nyx can successfully detected my traffic and two others join after my traffic(but in other time it's just ~700B/s w/o connection). And every-time I restart the tor service, it will up for some hours. There is no error or warning in log. More context: I setup my first relay on yesterday(>18hrs ago) on Ubuntu 24, Tor 0.4.8.18 following the guide; It's on KVM/QEMU VPS with some of my other services. the status is right here: <https://bridges.torproject.org/status?id=A69AD85C2E175BD0F753E1CCBE5D4BA371…> and <https://metrics.torproject.org/rs.html#details/A69AD85C2E175BD0F753E1CCBE5D…>. Do I need to allow some extra ports? right now I only accept the ORPort and block any others. Or it may relatives with my VPS ISP? -- Best, Eritque Arcus

3 3