Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-10-11T23:40:04Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25193dos: Avoid blacklisting Exit relays2022-10-11T23:40:04ZDavid Gouletdgoulet@torproject.orgdos: Avoid blacklisting Exit relaysIt is possible to do "tor-in-tor" meaning a tor client connection can exit the network and come back at a Guard node.
And if this happens to be detected by the DoS subsystem, we'll blacklist the Exit relay for a while. That is *NOT* goo...It is possible to do "tor-in-tor" meaning a tor client connection can exit the network and come back at a Guard node.
And if this happens to be detected by the DoS subsystem, we'll blacklist the Exit relay for a while. That is *NOT* good.
Now that we have legacy/trac#25183, we can lookup the inbound address to learn if we know it. And if we do, don't consider it a potential malicious client that we need to look at.
That is one part of the solution, the second part is legacy/trac#2667 so we actually prevent reentry from Exit but that part won't be backported just yet (if ever).
This work will be part of legacy/trac#24902 so once merge_ready, it will be merged into my branch `ticket24902_029_05`.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25183Implement a way to tell if an IP address is a known relay2022-10-11T23:40:04ZDavid Gouletdgoulet@torproject.orgImplement a way to tell if an IP address is a known relayFor the DoS mitigation subsystem (legacy/trac#24902), we need a way to lookup the connection address and *quickly* know if it is a known relay or not. This is also needed for legacy/trac#2667 which would prevent Exit to reenter the netwo...For the DoS mitigation subsystem (legacy/trac#24902), we need a way to lookup the connection address and *quickly* know if it is a known relay or not. This is also needed for legacy/trac#2667 which would prevent Exit to reenter the network.
nickm has started a branch to have IP addresses with bloom filter: `address_set_029`.
Next step is to use that and bridge it with the nodelist so we can lookup an IP address and learn if it is known or not (not get the `node_t` back, that would require more work and probably lose in performance).Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25141enabling CellStatistics results in gigabytes of incremental memory consumption2022-10-11T23:40:04Zstarlightenabling CellStatistics results in gigabytes of incremental memory consumptionThis was causing my relay to crash every two days till I figured it out. At a minimum Tor should warn about memory consumption when this option is enabled. IMO the present behavior is broken and the feature should be redesigned or elim...This was causing my relay to crash every two days till I figured it out. At a minimum Tor should warn about memory consumption when this option is enabled. IMO the present behavior is broken and the feature should be redesigned or eliminated.https://gitlab.torproject.org/tpo/core/tor/-/issues/25128Bug: src/or/dos.c:312: cc_stats_refill_bucket: Non-fatal assertion new_circui...2022-10-11T23:40:04ZDavid Gouletdgoulet@torproject.orgBug: src/or/dos.c:312: cc_stats_refill_bucket: Non-fatal assertion new_circuit_bucket_count >= stats->circuit_bucket failedI changed the `DoSCircuitCreationBurst` value in my torrc and this BUG() was triggered:
```
Feb 02 21:52:55.902 [warn] tor_bug_occurred_(): Bug: src/or/dos.c:312: cc_stats_refill_bucket: Non-fatal assertion new_circuit_bucket_count >= s...I changed the `DoSCircuitCreationBurst` value in my torrc and this BUG() was triggered:
```
Feb 02 21:52:55.902 [warn] tor_bug_occurred_(): Bug: src/or/dos.c:312: cc_stats_refill_bucket: Non-fatal assertion new_circuit_bucket_count >= stats->circuit_bucket failed. (on Tor 0.3.3.1-alpha-dev eafa252b26ecf83a)
Feb 02 21:52:55.903 [warn] Bug: Non-fatal assertion new_circuit_bucket_count >= stats->circuit_bucket failed in cc_stats_refill_bucket at src/or/dos.c:312. Stack trace: (on Tor 0.3.3.1-alpha-dev eafa252b26ecf83a)
Feb 02 21:52:55.903 [warn] Bug: /root/git/tor/src/or/tor(log_backtrace+0x42) [0x557248c2bbd2] (on Tor 0.3.3.1-alpha-dev eafa252b26ecf83a)
Feb 02 21:52:55.903 [warn] Bug: /root/git/tor/src/or/tor(tor_bug_occurred_+0xb9) [0x557248c46f69] (on Tor 0.3.3.1-alpha-dev eafa252b26ecf83a)
Feb 02 21:52:55.903 [warn] Bug: /root/git/tor/src/or/tor(dos_cc_new_create_cell+0x263) [0x557248bf1e63] (on Tor 0.3.3.1-alpha-dev eafa252b26ecf83a)
```
This is because of:
```
/* This function is not allowed to make the bucket count smaller */
tor_assert_nonfatal(new_circuit_bucket_count >= stats->circuit_bucket);
```
We actually can make it smaller if the Burst or Rate is changed at runtime.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/2509424902 fix breaks on clang2022-10-11T23:40:03ZTaylor Yu24902 fix breaks on clanghttps://travis-ci.org/torproject/tor/jobs/335395212#L1716
```
src/or/dos.c:277:40: error: implicit conversion loses integer precision: 'long'
to 'uint32_t' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
num_token = elapsed_tim...https://travis-ci.org/torproject/tor/jobs/335395212#L1716
```
src/or/dos.c:277:40: error: implicit conversion loses integer precision: 'long'
to 'uint32_t' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
num_token = elapsed_time_last_refill * circuit_rate;
~ ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
```Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24964dos: Block single hop client at the HSDir2022-10-11T23:40:03ZDavid Gouletdgoulet@torproject.orgdos: Block single hop client at the HSDirThis is so we remove load from spammy tor2web clients at the HSDir level.
Opened after discussion in legacy/trac#24902.This is so we remove load from spammy tor2web clients at the HSDir level.
Opened after discussion in legacy/trac#24902.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24849Added -1 signatures to consensus2022-10-11T23:40:03ZteorAdded -1 signatures to consensusThis line is also in the logs from legacy/trac#24815.
```
Jan 09 08:57:32.637 [info] dirvote_add_signatures_to_pending_consensus: Added -1 signatures to consensus.
```This line is also in the logs from legacy/trac#24815.
```
Jan 09 08:57:32.637 [info] dirvote_add_signatures_to_pending_consensus: Added -1 signatures to consensus.
```Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24815Validate shared random state dates before each voting period2022-10-11T23:40:03ZteorValidate shared random state dates before each voting periodWhen tor's clock jumps, the shared random state can get out of sync with the current round.
This happens to me on a test authority on a laptop that sleeps regularly. But it could also happen to authorities that miss a voting round becau...When tor's clock jumps, the shared random state can get out of sync with the current round.
This happens to me on a test authority on a laptop that sleeps regularly. But it could also happen to authorities that miss a voting round because they are under heavy load. (I have seen clock jumps happen on Linux and BSD under the recent heavy load.)
I see this message when I restart my authority:
```
Jan 07 09:48:13.179 [info] or_state_load: Loaded state from "/Users/USER/tor/auth/auth-sr-3e/state"
Jan 07 09:48:14.977 [info] disk_state_validate: SR: Disk state valid after/until times are invalid.
Jan 07 09:48:14.984 [info] sr_state_update: SR: State prepared for upcoming voting period (2018-01-06 23:00:00). Upcoming phase is reveal (counters: 0 commit & 1 reveal rounds).
Jan 07 09:48:16.026 [info] or_state_save: Saved state to "/Users/USER/tor/auth/auth-sr-3e/state"
```
Even though this message was logged just before I killed it:
```
Jan 07 09:47:45.328 [info] or_state_save: Saved state to "/Users/USER/tor/auth/auth-sr-3e/state"
```Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24782Set a lower default MaxMemInQueues value2022-10-11T23:40:02ZteorSet a lower default MaxMemInQueues valueThe default MaxMemInQueues value of 0.75*RAM assumes:
* there is one tor instance per machine, and
* MaxMemInQueues covers most queue memory.
If we instead assumed:
* two tor instances, and
* MaxMemInQueues covers half of queue memorym
...The default MaxMemInQueues value of 0.75*RAM assumes:
* there is one tor instance per machine, and
* MaxMemInQueues covers most queue memory.
If we instead assumed:
* two tor instances, and
* MaxMemInQueues covers half of queue memorym
this would make Tor more resilient to attacks.
To do this, we should set MaxMemInQueues to 0.2*RAM, at least if we have a lot of RAM (like 4-8GB or more).Tor: 0.3.3.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24671sched: KISTLite should set an upper limit to write on the outbuf2022-10-11T23:40:02ZDavid Gouletdgoulet@torproject.orgsched: KISTLite should set an upper limit to write on the outbufRight now, for the `KISTLite` scheduler, the write limit on the outbuf for a channel is set to `INT_MAX`. This is crazy high and will bloat the outbuf if the channel is struggling to send out data on the wire or the socket is stuck.
Van...Right now, for the `KISTLite` scheduler, the write limit on the outbuf for a channel is set to `INT_MAX`. This is crazy high and will bloat the outbuf if the channel is struggling to send out data on the wire or the socket is stuck.
Vanilla scheduler uses the `num_cells_writeable()` method to limit the amount it puts on the outbuf which is 32KB maximum.
KIST uses the kernel information for this limit.
This is very important that we actually put a limit in the outbuf because it keeps the cells in the circuit queue and that is handled by our OOM in case of memory pressure.
I suggest we simply use the `channel_num_cells_writeable()` for the upper limit when KISTLite is used.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24299Allow onion services to distinguish clients from each other2022-10-11T23:40:02ZGeorge KadianakisAllow onion services to distinguish clients from each otherWe should provide onion services with the option to distinguish their anonymous users from each other, and also to handle those clients in a clinical way to do diagnostics, rate-limiting, abusive client blocking, etc.
One proposed way t...We should provide onion services with the option to distinguish their anonymous users from each other, and also to handle those clients in a clinical way to do diagnostics, rate-limiting, abusive client blocking, etc.
One proposed way to do so comes from an old tor-dev thread which suggests we assign a virtual IP to each client based on the circuit ID:
https://lists.torproject.org/pipermail/tor-dev/2014-March/006610.html
I2P seems to have implemented a derivative of this idea. I wonder how it works for them:
https://github.com/i2p/i2p.i2p/blob/920b14212fa80a3a0e92d6e919fdae7e39ed22d5/apps/i2ptunnel/java/src/net/i2p/i2ptunnel/I2PTunnelServer.java#L739Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24298Better handling of DoS attacks on onion services2022-10-11T23:40:02ZGeorge KadianakisBetter handling of DoS attacks on onion servicesWe have received various reports on attackers being able to DoS onion services in various ways. Examples:
a) Layer-7 attacks where the attacker spams HTTP requests: https://www.hackerfactor.com/blog/index.php?/archives/777-Stopping-Tor-...We have received various reports on attackers being able to DoS onion services in various ways. Examples:
a) Layer-7 attacks where the attacker spams HTTP requests: https://www.hackerfactor.com/blog/index.php?/archives/777-Stopping-Tor-Attacks.html
b) DoS through the Tor protocol (intense circuit construction #16052m legacy/trac#15515).
We should come up with designs and plans on how to mitigate those DoS attacks better in the future.
Due to the anonymous unlinkable nature of Tor onion service clients, these designs should be modular enough so that onion service operators can write their own anti-DoS modules to handle specific cases of attacks.
This is a parent ticket to handle the various subtasks.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30466hs: Do not allow more than one control cell on a circuit2022-10-11T23:39:50ZDavid Gouletdgoulet@torproject.orghs: Do not allow more than one control cell on a circuitThis is the list of HS control cell that is they are all for establishing a circuit or/and "connection" between HS entities (IP, RP, Service, client):
```
RELAY_COMMAND_ESTABLISH_INTRO:
RELAY_COMMAND_ESTABLISH_RENDEZVOUS:
RELAY_COMMAND_...This is the list of HS control cell that is they are all for establishing a circuit or/and "connection" between HS entities (IP, RP, Service, client):
```
RELAY_COMMAND_ESTABLISH_INTRO:
RELAY_COMMAND_ESTABLISH_RENDEZVOUS:
RELAY_COMMAND_INTRODUCE1:
RELAY_COMMAND_INTRODUCE2:
RELAY_COMMAND_INTRODUCE_ACK:
RELAY_COMMAND_INTRO_ESTABLISHED:
RELAY_COMMAND_RENDEZVOUS1:
RELAY_COMMAND_RENDEZVOUS2:
RELAY_COMMAND_RENDEZVOUS_ESTABLISHED:
```
It appears that anyone can send an arbitrary amount of those cells on the same circuit. Even to the point that tor allows a rendezvous circuit to become an intro circuit.
The only special one is `INTRODUCE2` which is by-design are sent a lot on the same circuit.
The only cell currently limited to 1 cell is `INTRODUCE1` since we do not allow multiple introductions on the same client circuit for DoS reasons.
But the rest should only be seen *once* on a circuit. Lets restrict them and if we see more, then we close the circuit due to a protocol error. This would limit side-channels.https://gitlab.torproject.org/tpo/core/tor/-/issues/30308Use tor_mem_is_zero to check for broken node identity in node_is_a_configured...2022-10-11T23:39:50ZNick MathewsonUse tor_mem_is_zero to check for broken node identity in node_is_a_configured_bridge()In node_is_a_configured_bridge(), we use `BUG(tor_digest_is_zero(...))` to check for a broken node_t whose digest is not set. But that's overkill: tor_digest_is_zero() uses the slow constant-time tor_memeq(), and this is a case where we...In node_is_a_configured_bridge(), we use `BUG(tor_digest_is_zero(...))` to check for a broken node_t whose digest is not set. But that's overkill: tor_digest_is_zero() uses the slow constant-time tor_memeq(), and this is a case where we will hit a BUG().Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30307Make router_choose_random_node() linear instead of quadratic2022-10-11T23:39:50ZNick MathewsonMake router_choose_random_node() linear instead of quadraticSee parent for motivation.
The smartlist_subtract() function is O(m*n), so we should try not to use it here if we can.See parent for motivation.
The smartlist_subtract() function is O(m*n), so we should try not to use it here if we can.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30221HS performance optimizations of codebase (master ticket)2022-10-11T23:39:49ZGeorge KadianakisHS performance optimizations of codebase (master ticket)Here is a master ticket for various tickets that have crept through the years suggesting improvements of various costly HS functions.Here is a master ticket for various tickets that have crept through the years suggesting improvements of various costly HS functions.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30220Consider proof-of-rendezvous as a way to decrease INTRODUCE2 flood2022-10-11T23:39:49ZGeorge KadianakisConsider proof-of-rendezvous as a way to decrease INTRODUCE2 floodTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29637Denial of service on v2 onion service2022-10-11T23:39:49ZTracDenial of service on v2 onion serviceDear tor team,
We have setup a discussion board, on the tor network.
And there is someone that is exploiting within our servers, by taking it down it every time and the forums will respond with "Server not found".
We are pretty sure this...Dear tor team,
We have setup a discussion board, on the tor network.
And there is someone that is exploiting within our servers, by taking it down it every time and the forums will respond with "Server not found".
We are pretty sure this problem is on the side of the TOR browser, is there anything we could do to sort this?
With many thanks for taking time into reading this.
The other ticket was closed, cause i could not reply to question why it's on tor side.
My answer to that :
the service behind onion HiddenService is fine, it is serving requests.
before the DDOS there have not been "Server Not Found".
Actually it was the hackers third iteration.
First step from hacker was brute force DDOS which made tor cpu load 100%. countermeasure: vanguards and using ExcludeNodes (torrc)
Second iteration from hacker was to use random nodes, about 1000+, to do tor cpu load 100%. countermeasure: vanguards / onionbalance.
now tor browser gives "server not found", countermeasure not found yet
Also some server sided information :
onionbalance is active
vanguard is active
vanguard tor process is at 5%
serving tor process is at 5%
attacker has found a way to DDOS not based on tor cpu usage attack or tor traffic exhaust attack.
I also appoligize for the duplicate ticket, but the others are closed so this one should be fine for now.
With many thanks.
**Trac**:
**Username**: pidginTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/296072019 Q1: Denial of service on v2 and v3 onion service2022-10-11T23:39:49ZTrac2019 Q1: Denial of service on v2 and v3 onion serviceDear tor team,
We have setup a discussion board, on the tor network.
And there is someone that is exploiting within our servers, by taking it down it every time and the forums will respond with "Server not found".
We are pretty sure this...Dear tor team,
We have setup a discussion board, on the tor network.
And there is someone that is exploiting within our servers, by taking it down it every time and the forums will respond with "Server not found".
We are pretty sure this problem is on the side of the TOR browser, is there anything we could do to sort this?
With many thanks for taking time into reading this.
**Trac**:
**Username**: pidginTor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28514Open NUM_PARALLEL_TESTING_CIRCS when a bandwidth test is initiated2022-10-11T23:39:49ZteorOpen NUM_PARALLEL_TESTING_CIRCS when a bandwidth test is initiatedAfter we put a limit on the number of testing circuits (legacy/trac#28511), we can open NUM_PARALLEL_TESTING_CIRCS*3/2 circuits when we start testing bandwidth. Otherwise, circuits can time out and be replaced with new circuits, leading ...After we put a limit on the number of testing circuits (legacy/trac#28511), we can open NUM_PARALLEL_TESTING_CIRCS*3/2 circuits when we start testing bandwidth. Otherwise, circuits can time out and be replaced with new circuits, leading to a DoS.Tor: unspecified