Tor 0.4.9.15 released - New DoS defenses
Greetings operators! Today, we released tor 0.4.9.15 which contains three new DoS defenses aimed at mitigating the BEGIN_DIR thunderstorm attack we've all been experiencing. Quick data point (or refresher): BEGIN_DIR is a cell type that tor uses to send directory documents requests (ex: fetch consensus) over a circuit. Here are the details of the defenses and what to expect on the MetricsPort. 1. BEGIN_DIR rate limit per circuit: default On Exactly like the stream DoS defense (DoSStreamCreationRate), we put in a rate limit for BEGIN_DIR which applies to relays and bridges. With it, 4 new torrc options that are also consensus parameters: DoSBeginDirRateEnabled (default 1), DoSBeginDirRate (default 10) DoSBeginDirBurst (default 60) DoSBeginDirDefenseType (1 = no defense, 2 = refuse the stream, 3 = close the circuit; default 3). You DO NOT need to set these, please leave the consensus set those at the moment. MetricsPort new counter which is also present in the DoS heartbeat log line: tor_relay_dos_total{type="begindir_rate_rejected"} 2. One BEGIN_DIR per circuit from relays: default Off. A circuit that arrives from another relay, meaning its previous hop authenticated as a relay, may carry only one BEGIN_DIR over its whole lifetime. This behavior is solely controlled by the consensus with DoSBeginDirLimitEnabled as it shouldn't be flipped on individual relays as it can possibly lead to network degradation. We need most of the network to upgrade before we can turn this on. MetricsPort new counter which is also present in the DoS heartbeat log line: tor_relay_dos_total{type="begindir_rejected"} 3. One HSDir request per circuit: Always On. An HSDir now accepts at most one onion service descriptor fetch or upload per circuit. A second HS descriptor request on the same circuit closes the circuit. MetricsPort new counter which is also present in the DoS heartbeat log line: tor_relay_dos_total{type="begindir_hsdir_rejected"} We expect these defenses to mitigate the vast majority of BEGIN_DIR requests that we are seeing from this attack. However, this won't magically make the hundreds of circuits per second we see on a single relay disappear. You will still experience an heavy load as long as the attacker is doing their thing... There is also a big change to how directory authorities assign the HSDir flag, it is now sticky, meaning it survives a relay restart. A relay still needs 96 hours of uptime to get the HSDir flag the first time but once it has the flag and stays in the consensus, it keeps it. If your relay drops out of the consensus, the uptime requirement applies again. All other HSDir requirements (Stable, Fast, Running, DirCache 1) still apply as before. At this moment, we have a majority of authorities already upgraded to 0.4.9.15. One last important point. If you added "DirCache 0" to your torrc during this DoS attack, please remove it and see if things improve for your relay. The main issue with disabling DirCache is that you're effectively opting out of serving as a Fallbackdir, Guard, HSDir, and a directory cache. The network really needs these nodes so we'd strongly encourage you to revert that option. These are significant changes so we'd appreciate everyone's help in letting us know if you notice anything wrong or behaving unexpectedly. You can do so by writing on this list or via our Gitlab at https://gitlab.torproject.org. None of this work would have been possible without the help of several relay operators who generously gave their time and knowledge. We can't thank you enough for your help and to everyone running relays!!! Cheers! David -- MCgfKt8Z71zgn/ZfkxQViFHsfNFGHjprU2EQX+0o9HQ=
I have just updated my relay :-) Thank You. On Wed, 28 Oct 2026, David Goulet via tor-relays wrote:
Greetings operators!
Today, we released tor 0.4.9.15 which contains three new DoS defenses aimed at mitigating the BEGIN_DIR thunderstorm attack we've all been experiencing.
Quick data point (or refresher): BEGIN_DIR is a cell type that tor uses to send directory documents requests (ex: fetch consensus) over a circuit.
Here are the details of the defenses and what to expect on the MetricsPort.
1. BEGIN_DIR rate limit per circuit: default On
Exactly like the stream DoS defense (DoSStreamCreationRate), we put in a rate limit for BEGIN_DIR which applies to relays and bridges.
With it, 4 new torrc options that are also consensus parameters:
DoSBeginDirRateEnabled (default 1), DoSBeginDirRate (default 10) DoSBeginDirBurst (default 60) DoSBeginDirDefenseType (1 = no defense, 2 = refuse the stream, 3 = close the circuit; default 3).
You DO NOT need to set these, please leave the consensus set those at the moment.
MetricsPort new counter which is also present in the DoS heartbeat log line:
tor_relay_dos_total{type="begindir_rate_rejected"}
2. One BEGIN_DIR per circuit from relays: default Off.
A circuit that arrives from another relay, meaning its previous hop authenticated as a relay, may carry only one BEGIN_DIR over its whole lifetime.
This behavior is solely controlled by the consensus with DoSBeginDirLimitEnabled as it shouldn't be flipped on individual relays as it can possibly lead to network degradation. We need most of the network to upgrade before we can turn this on.
MetricsPort new counter which is also present in the DoS heartbeat log line:
tor_relay_dos_total{type="begindir_rejected"}
3. One HSDir request per circuit: Always On.
An HSDir now accepts at most one onion service descriptor fetch or upload per circuit. A second HS descriptor request on the same circuit closes the circuit.
MetricsPort new counter which is also present in the DoS heartbeat log line:
tor_relay_dos_total{type="begindir_hsdir_rejected"}
We expect these defenses to mitigate the vast majority of BEGIN_DIR requests that we are seeing from this attack. However, this won't magically make the hundreds of circuits per second we see on a single relay disappear. You will still experience an heavy load as long as the attacker is doing their thing...
There is also a big change to how directory authorities assign the HSDir flag, it is now sticky, meaning it survives a relay restart. A relay still needs 96 hours of uptime to get the HSDir flag the first time but once it has the flag and stays in the consensus, it keeps it. If your relay drops out of the consensus, the uptime requirement applies again. All other HSDir requirements (Stable, Fast, Running, DirCache 1) still apply as before. At this moment, we have a majority of authorities already upgraded to 0.4.9.15.
One last important point. If you added "DirCache 0" to your torrc during this DoS attack, please remove it and see if things improve for your relay. The main issue with disabling DirCache is that you're effectively opting out of serving as a Fallbackdir, Guard, HSDir, and a directory cache. The network really needs these nodes so we'd strongly encourage you to revert that option.
These are significant changes so we'd appreciate everyone's help in letting us know if you notice anything wrong or behaving unexpectedly. You can do so by writing on this list or via our Gitlab at https://gitlab.torproject.org.
None of this work would have been possible without the help of several relay operators who generously gave their time and knowledge. We can't thank you enough for your help and to everyone running relays!!!
Cheers! David
-- MCgfKt8Z71zgn/ZfkxQViFHsfNFGHjprU2EQX+0o9HQ=
* David Goulet via tor-relays:
Today, we released tor 0.4.9.15 which contains three new DoS defenses aimed at mitigating the BEGIN_DIR thunderstorm attack we've all been experiencing.
I have not expressed my thanks to the Tor team for quite a while, and I think this is a suitable occasion to remedy my silence. Thank you for your continued work to make Tor safer and more resilient in the face of hostile actors. I imagine that the serious attackers out there can draw on greater numbers in both manpower and budget, and still the Tor team fights back. I find this impressive. -Ralph
Amazing work! Optimistic to see the improvements! Starting to roll out now. Also, expecting lower CPU utilization or more efficient flood handling as 0.4.9.14 had the one core CPU main thread pinned around 100% due to some bottlenecks that were fixed! Amazing work eliminating the O(N^2) connection-teardown and BEGIN_DIR linked-read CPU bottlenecks by tracking O(1) swap-delete indices across connection_array, closeable_connection_lst, and active_linked_connection_lst through a single unified connection_list_index() helper. Even better, guarding index lookups and direct connection_free_() calls on active connections with non-fatal BUG() diagnostics that self-heal via smartlist_pos() prevents duplicate list entries and dangling pointers without risking a fatal assertion crash on a live relay. We had a patch ready that didn't fallback as gracefully. Glad we don't need it! On to the next set of bottlenecks. On Wednesday, October 28th, 2026 at 11:26 AM, David Goulet via tor-relays <tor-relays@lists.torproject.org> wrote:
Greetings operators!
Today, we released tor 0.4.9.15 which contains three new DoS defenses aimed at mitigating the BEGIN_DIR thunderstorm attack we've all been experiencing.
Quick data point (or refresher): BEGIN_DIR is a cell type that tor uses to send directory documents requests (ex: fetch consensus) over a circuit.
Here are the details of the defenses and what to expect on the MetricsPort.
1. BEGIN_DIR rate limit per circuit: default On
Exactly like the stream DoS defense (DoSStreamCreationRate), we put in a rate limit for BEGIN_DIR which applies to relays and bridges.
With it, 4 new torrc options that are also consensus parameters:
DoSBeginDirRateEnabled (default 1), DoSBeginDirRate (default 10) DoSBeginDirBurst (default 60) DoSBeginDirDefenseType (1 = no defense, 2 = refuse the stream, 3 = close the circuit; default 3).
You DO NOT need to set these, please leave the consensus set those at the moment.
MetricsPort new counter which is also present in the DoS heartbeat log line:
tor_relay_dos_total{type="begindir_rate_rejected"}
2. One BEGIN_DIR per circuit from relays: default Off.
A circuit that arrives from another relay, meaning its previous hop authenticated as a relay, may carry only one BEGIN_DIR over its whole lifetime.
This behavior is solely controlled by the consensus with DoSBeginDirLimitEnabled as it shouldn't be flipped on individual relays as it can possibly lead to network degradation. We need most of the network to upgrade before we can turn this on.
MetricsPort new counter which is also present in the DoS heartbeat log line:
tor_relay_dos_total{type="begindir_rejected"}
3. One HSDir request per circuit: Always On.
An HSDir now accepts at most one onion service descriptor fetch or upload per circuit. A second HS descriptor request on the same circuit closes the circuit.
MetricsPort new counter which is also present in the DoS heartbeat log line:
tor_relay_dos_total{type="begindir_hsdir_rejected"}
We expect these defenses to mitigate the vast majority of BEGIN_DIR requests that we are seeing from this attack. However, this won't magically make the hundreds of circuits per second we see on a single relay disappear. You will still experience an heavy load as long as the attacker is doing their thing...
There is also a big change to how directory authorities assign the HSDir flag, it is now sticky, meaning it survives a relay restart. A relay still needs 96 hours of uptime to get the HSDir flag the first time but once it has the flag and stays in the consensus, it keeps it. If your relay drops out of the consensus, the uptime requirement applies again. All other HSDir requirements (Stable, Fast, Running, DirCache 1) still apply as before. At this moment, we have a majority of authorities already upgraded to 0.4.9.15.
One last important point. If you added "DirCache 0" to your torrc during this DoS attack, please remove it and see if things improve for your relay. The main issue with disabling DirCache is that you're effectively opting out of serving as a Fallbackdir, Guard, HSDir, and a directory cache. The network really needs these nodes so we'd strongly encourage you to revert that option.
These are significant changes so we'd appreciate everyone's help in letting us know if you notice anything wrong or behaving unexpectedly. You can do so by writing on this list or via our Gitlab at https://gitlab.torproject.org.
None of this work would have been possible without the help of several relay operators who generously gave their time and knowledge. We can't thank you enough for your help and to everyone running relays!!!
Cheers! David
-- MCgfKt8Z71zgn/ZfkxQViFHsfNFGHjprU2EQX+0o9HQ= _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
Hi guys Is the new update working well? I dont have the flags yet because ive lost them five times because of the attacks so im interested to hear
_______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
Since I got the flags back I think the attacker has been back. 10% more tx than rx. Traffic is ramping up but so far the relay is running fine. Normal CPU so no risk of losing flags again *fingers crossed* On 10/30/26 16:59, kullikovana via tor-relays wrote:
Hi guys Is the new update working well? I dont have the flags yet because ive lost them five times because of the attacks so im interested to hear
_______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
_______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
On Wednesday, 28 October 2026 19:19:44 CET David Goulet via tor-relays wrote:
There is also a big change to how directory authorities assign the HSDir flag, it is now sticky, meaning it survives a relay restart. A relay still needs 96 hours of uptime to get the HSDir flag the first time but once it has the flag and stays in the consensus, it keeps it. If your relay drops out of the consensus, the uptime requirement applies again. All other HSDir requirements (Stable, Fast, Running, DirCache 1) still apply as before.
:-) Oh, lovely—that’s something I (and many others) have been wishing for for a long time. Hopefully, this will make the attacks more time-consuming and expensive. I'm in favor of a 'ramp-up' phase for Guard, exit¹ & HSDir flag. ¹AFAIK, it's being planned for Arti. -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
participants (7)
-
3hn92a＠cock.li -
boldsuck -
David Goulet -
kullikovana -
Logforme -
Ralph Seichter -
Tor at 1AEO