Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:04Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33894make (retroactive) proposal for DoS subsystem2020-06-13T15:53:04ZRoger Dingledinemake (retroactive) proposal for DoS subsystemIn #24902, dgoulet speaks of a ddos-design.txt document.
But there is no actual proposal for the overall DoS subsystem.
If we have the document around, and we just never published it, this is a great chance to notice, clean it up a bit...In #24902, dgoulet speaks of a ddos-design.txt document.
But there is no actual proposal for the overall DoS subsystem.
If we have the document around, and we just never published it, this is a great chance to notice, clean it up a bit, and call it proposal three-hundred-and-something. (And then maybe turn some of it into one of the spec files if that makes sense, but, one step at a time here. :)
Motivated by this month's tor-dev thread where all we have to show for the DoS subsystem design is a trac ticket number and a changelog entry.Tor: unspecifiedDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33844Do next iteration of proposal by folding in comments from dgoulet/mike2020-06-13T15:52:58ZGeorge KadianakisDo next iteration of proposal by folding in comments from dgoulet/mikeThis is just a ticket to track progress: making the next iteration of the proposal based on dgoulet/mike comments is the next step here.This is just a ticket to track progress: making the next iteration of the proposal based on dgoulet/mike comments is the next step here.Tor: unspecifiedGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/33843Write detailed priority queue scheduler design on the proposal2020-06-13T15:52:57ZGeorge KadianakisWrite detailed priority queue scheduler design on the proposalTor: unspecifiedDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33712Design a PoW scheme for HS DoS defence2020-06-13T15:52:35ZGeorge KadianakisDesign a PoW scheme for HS DoS defenceSome initial research has been done on comment:13:ticket:31223 to sketch out a PoW/credential scheme that works for HS DoS defence.
This ticket is to continue scheming and working on this design.
See https://lists.torproject.org/piperm...Some initial research has been done on comment:13:ticket:31223 to sketch out a PoW/credential scheme that works for HS DoS defence.
This ticket is to continue scheming and working on this design.
See https://lists.torproject.org/pipermail/tor-dev/2020-April/014215.html for initial proposal.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33704Understand code performance of onion services under DoS2020-06-13T15:52:34ZGeorge KadianakisUnderstand code performance of onion services under DoSWe need to do the following experiments to understand more about the performance of Tor under simulated DoS conditions:
1) Get vanilla profile (for #30221) [VANILLA profile] [Also get with INTRO2 rate limiting]
2) See effect of DoS on ...We need to do the following experiments to understand more about the performance of Tor under simulated DoS conditions:
1) Get vanilla profile (for #30221) [VANILLA profile] [Also get with INTRO2 rate limiting]
2) See effect of DoS on intro and guard [VANILLA profile] [Also with INTRO2 rate limiting]
3) Investigate control port experiment (with STREAM events enabled and trying to kill circs with CLOSECIRCUIT) [VANILLA profile]
wrt https://lists.torproject.org/pipermail/tor-dev/2019-December/014097.html
NEED: Controller script that logs circuit events and tries to kill some circuits [asn]
4) Investigate size of replay cache (#26294) [VANILLA profile] [asn]
5) Investigate capacity of reestablish intro circuit (#26294) [VANILLA profile]
6) Compare intro/rend profiles (value of prop255 / #17254) [VANILLA profile]
7~) Investigate horizontal scaling with OB (scale to 2/4/8 instances, extrapolate onwards.) [OBv3 profile]
8~) Investigate pinned paths with HSLayer2Node HSLayer3Node [Vanguard profile]Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33703Improving HS availability under DoS (master ticket)2020-06-13T15:52:33ZGeorge KadianakisImproving HS availability under DoS (master ticket)This is the master ticket for organizing work under this topic.This is the master ticket for organizing work under this topic.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33650Verify that intro2 cell extensions actually work2020-06-13T15:52:23ZRoger DingledineVerify that intro2 cell extensions actually workIn the future we're going to want to transport end-to-end tokens, proofs of work, or other blobs from client to onion service. We should make sure that we can actually add these into the cells without anything going wrong, like surprisin...In the future we're going to want to transport end-to-end tokens, proofs of work, or other blobs from client to onion service. We should make sure that we can actually add these into the cells without anything going wrong, like surprising asserts or surprising length enforcement.
(Now is the time to notice if things will go wrong, so we can fix them and deploy that fix, and then people will have upgraded by the time we're ready to actually use them.)
So: let's make a branch that adds "hi mom" on the client side, and reads it out again on the service side.
In spelunking through the code and the spec, I found that modern intro2 cells have an "extensions" field inside their encrypted component, which seems perfectly suited for transporting arbitrary blobs from client to service. Here's how we set it currently on the client side:
```
/* Set extension data. None are used. */
ext = trn_cell_extension_new();
tor_assert(ext);
trn_cell_extension_set_num(ext, 0);
trn_cell_introduce_encrypted_set_extensions(enc_cell, ext);
```
So that 0 needs to become a 1, and then we need something new that makes and sets a new extension in ext (modeled maybe on `build_establish_intro_dos_extension()`, and something on the receiving end that invokes trn_cell_extension_parse() and reads it out to us.
I am optimistic, because this thing is encrypted, so the intro point in the middle can't be looking at it very carefully. But if we have bugs on the client side or the service side, or surprise length enforcement in the middle, now is a great time to notice and fix them.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/33491tor_bug_occurred_: Bug: src/core/or/dos.c:697: dos_new_client_conn: Non-fatal...2020-06-13T15:51:55ZTractor_bug_occurred_: Bug: src/core/or/dos.c:697: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.6 )Hi there,
Receiving the below report, searched for 'src/core/or/dos.c:697' no hits, so opening ticket, please let me know if further info is needed to troubleshoot.
FreeBSD <<hostname>> 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC ...Hi there,
Receiving the below report, searched for 'src/core/or/dos.c:697' no hits, so opening ticket, please let me know if further info is needed to troubleshoot.
FreeBSD <<hostname>> 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC amd64
```
Mar 1 13:53:33 <<hostname>> Tor[86742]: tor_bug_occurred_: Bug: src/core/or/dos.c:697: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: Tor 0.4.2.6: Non-fatal assertion !(entry == NULL) failed in dos_new_client_conn at src/core/or/dos.c:697. Stack trace: (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x12f4acc <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x12f0b76 <tor_bug_occurred_+0x1d6> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x118d9a5 <channel_do_open_actions+0xf5> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x118d88e <channel_change_state_open+0x2e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x1191a57 <channel_tls_handle_state_change_on_orconn+0x67> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x1144946 <connection_or_set_state_open+0x26> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x11923ee <channel_tls_handle_cell+0x88e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x1140d52 <connection_or_process_inbuf+0x152> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x114ddad <connection_handle_read+0x8fd> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x119e3ee <connection_add_impl+0x23e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x8013d72b3 <event_base_assert_ok_nolock_+0xc23> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x8013d318f <event_base_loop+0x53f> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x11a0881 <do_main_loop+0xf1> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x113de68 <tor_run_main+0x128> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x113c656 <tor_main+0x66> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x113c309 <main+0x19> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: tor_bug_occurred_: Bug: src/core/or/dos.c:697: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: Tor 0.4.2.6: Non-fatal assertion !(entry == NULL) failed in dos_new_client_conn at src/core/or/dos.c:697. Stack trace: (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x12f4acc <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x12f0b76 <tor_bug_occurred_+0x1d6> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x118d9a5 <channel_do_open_actions+0xf5> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x118d88e <channel_change_state_open+0x2e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x1191a57 <channel_tls_handle_state_change_on_orconn+0x67> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x1144946 <connection_or_set_state_open+0x26> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x11923ee <channel_tls_handle_cell+0x88e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x1140d52 <connection_or_process_inbuf+0x152> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x114ddad <connection_handle_read+0x8fd> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x119e3ee <connection_add_impl+0x23e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x8013d72b3 <event_base_assert_ok_nolock_+0xc23> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x8013d318f <event_base_loop+0x53f> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x11a0881 <do_main_loop+0xf1> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x113de68 <tor_run_main+0x128> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x113c656 <tor_main+0x66> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x113c309 <main+0x19> at /usr/local/bin/tor (on Tor 0.4.2.6 )
```
**Trac**:
**Username**: sjcjonkerTor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32604Add HiddenServiceExportRendPoint and HiddenServiceExportInstanceID directive2020-06-13T15:48:33ZTracAdd HiddenServiceExportRendPoint and HiddenServiceExportInstanceID directiveAdd HiddenServiceExportRendPoint and HiddenServiceExportInstanceID directive to export rendezvous point information and instance ID along with circuit ID
**Trac**:
**Username**: moonsikparkAdd HiddenServiceExportRendPoint and HiddenServiceExportInstanceID directive to export rendezvous point information and instance ID along with circuit ID
**Trac**:
**Username**: moonsikparkTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/31754Add HS DoS defence stats to heartbeat2020-06-13T15:45:38ZGeorge KadianakisAdd HS DoS defence stats to heartbeatWe should add entries to our heartbeat about the new DoS defences we added to see how helpful and prevalent they are.
In particular:
- We should mention how many single-hop connections we blocked (#24962)
- How many times we applied rat...We should add entries to our heartbeat about the new DoS defences we added to see how helpful and prevalent they are.
In particular:
- We should mention how many single-hop connections we blocked (#24962)
- How many times we applied rate-limiting as an introduction point (#15516).
(Marking this as easy since the heartbeat module is not too hard to figure out)Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/31223Research approaches for improving the availability of services under DoS2020-06-13T15:43:46ZGeorge KadianakisResearch approaches for improving the availability of services under DoSWe've been improving the health of the network during onion service DoS, but not the onion service availability. This is a task for looking at this angle.
During the related Stockholm session we looked into various approaches that could...We've been improving the health of the network during onion service DoS, but not the onion service availability. This is a task for looking at this angle.
During the related Stockholm session we looked into various approaches that could help us towards that goal. Here are some of them:
- Introducing application-layer anonymous tokens that allow legit clients to get priority over DoS attacker
- PoW approaches like argon2
- CAPTCHA approaches like introducing a token server giving reCAPTCHA tokens
- Hiding introduction points by rate limiting how quickly clients can find them. Valet nodes?
- Having intros check that clients don't use the same IP over and over. Proof-of-existence?
- Pay bitcoin to introduce
Each of the above solutions has problems and this is a ticket to investigate at least the most promising of them, and attempt to move forward with something.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30620HS DDos on circuits? Can't have access to my hidden service2020-06-13T15:41:43ZTracHS DDos on circuits? Can't have access to my hidden serviceI do run a HS and i am getting attacked by a ddos. It was on layer7, then tcp, and now i think it's currently going in tor.
Tor debugs is been like 3MB weight in less than one second, with that query spammed:
circuit_build_times_add_ti...I do run a HS and i am getting attacked by a ddos. It was on layer7, then tcp, and now i think it's currently going in tor.
Tor debugs is been like 3MB weight in less than one second, with that query spammed:
circuit_build_times_add_time(): Adding circuit build time (random value)
3MB of that.
If i manage to start tor service i get:
May 25 21:21:19.000 [warn] Possible replay detected! An INTRODUCE2 cell with thesame ENCRYPTED section was seen 2 seconds ago. Dropping cell.
May 25 21:21:20.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 126 buildtimes.
May 25 21:21:41.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 1000 buildtimes.
May 25 21:22:06.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 1000 buildtimes.
May 25 21:22:33.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 1000 buildtimes.
May 25 21:23:33.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 1000 buildtimes.
May 25 21:23:46.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 368 buildtimes.
May 25 21:24:30.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 1000 buildtimes.
May 25 21:24:37.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 261 buildtimes.
May 25 21:24:45.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 296 buildtimes.
May 25 21:24:49.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 152 buildtimes.
May 25 21:25:17.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 942 buildtimes.
May 25 21:25:22.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 117 buildtimes.
May 25 21:25:29.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 132 buildtimes.
May 25 21:25:34.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 161 buildtimes.
May 25 21:25:40.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 118 buildtimes.
May 25 21:25:45.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 117 buildtimes.
May 25 21:25:50.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 149 buildtimes.
May 25 21:26:05.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 613 buildtimes.
May 25 21:26:12.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 205 buildtimes.
May 25 21:26:17.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 117 buildtimes.
Things like that all the time.
How to get around that?
**Trac**:
**Username**: HSdir123Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30520Onion Service (v2) hosting Tor instance reporting under high load: Failed to ...2020-06-13T15:41:32Zs7rOnion Service (v2) hosting Tor instance reporting under high load: Failed to find node for hop #1 of our path. Discarding this circuit.An onion hosting Tor instance is reporting strange stuff for the last 3 days. The server was attacked (DOS / SYN Flood last days), so maybe this could have triggered some network connection changes but the connection remained active / on...An onion hosting Tor instance is reporting strange stuff for the last 3 days. The server was attacked (DOS / SYN Flood last days), so maybe this could have triggered some network connection changes but the connection remained active / online. The torrc is very simple:
```
SocksPort 127.0.0.1:9050
ControlPort 0
HiddenServiceDir /var/lib/tor/tor_hs
HiddenServiceVersion 2
HiddenServicePort <port> 127.0.0.1:<port>
```
1)
```
May 12 11:16:08.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 362 buildtimes.
May 12 22:20:32.000 [notice] No circuits are opened. Relaxed timeout for circuit 398807 (a Hidden service: Connecting to rendezvous point 4-hop circuit in state doing handshakes with channel state open) to 106324ms. However, it appears the circuit has timed out anyway. [16 similar message(s) suppressed in last 3600 seconds]
```
2)
```
May 13 11:05:36.000 [notice] No circuits are opened. Relaxed timeout for circuit 399137 (a General-purpose client 3-hop circuit in state waiting to see how other guards perform with channel state open) to 106324ms. However, it appears the circuit has timed out anyway. [27 similar message(s) suppressed in last 3600 seconds]
```
3)
```
May 14 21:27:36.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.
May 14 21:27:36.000 [notice] Our circuit 0 (id: 400112) died due to an invalid selected path, purpose General-purpose client. This may be a torrc configuration issue, or a bug. [8 similar message(s) suppressed in last 3600 seconds]
```
I wish I could reproduce the last one. Could this be a bug that occurs when our primary #1 Guard is in consensus but not reachable just for a certain machine / IP?Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30466hs: Do not allow more than one control cell on a circuit2020-06-13T15:41:27ZDavid 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.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30308Use tor_mem_is_zero to check for broken node identity in node_is_a_configured...2020-06-13T15:41:03ZNick 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/legacy/trac/-/issues/30307Make router_choose_random_node() linear instead of quadratic2020-06-13T15:41:03ZNick 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/legacy/trac/-/issues/30291Optimize our path selection code2020-06-13T15:40:59ZDavid Gouletdgoulet@torproject.orgOptimize our path selection code(This is a more complete ticket than #13739 and thus supersedes it.)
An onion service can be ask to open many rendezvous circuit by a client. With a vanilla Tor, the resource consumption there is roughly 1:2 (service:client) because the...(This is a more complete ticket than #13739 and thus supersedes it.)
An onion service can be ask to open many rendezvous circuit by a client. With a vanilla Tor, the resource consumption there is roughly 1:2 (service:client) because the client needs to open two circuits, one to the RP and one to the IP and then sends one cell on that circuit to introduce. The service will do a bit less than that because its introduction circuit is already established so it simply needs to open a rendezvous circuit.
However, an attacker (DoS) can make a client skip the RP circuit creation, pin relays in a path to the introduction point and simply open an introduction circuit each time through that path (which in theory should be made very fast and also controlled by the attacker).
This means that the work ratio goes from 1:2 to 1:1 because the client only opens one circuit, send a single cell, close it and repeat.
But, in reality, it gets worst for the service because of the performance of our path selection code. It is heavy. For starter, we need to randomly select 3 nodes from the consensus for each rendezvous circuit. But to select those nodes, we go over all of them for each node to exclude some, include others, go through a series of tests such has `tor_addr_family()` and `node_has_preferred_descriptor()` that are quite heavy.
The CPU profile of an overloaded service shows that the majority of CPU is spent in selecting these nodes. Here is a perf report output for the top 5:
```
+ 11.10% tor tor [.] smartlist_remove
+ 10.96% tor tor [.] fmonty
+ 8.77% tor tor [.] tor_memeq
+ 6.56% tor tor [.] tor_addr_family
+ 5.40% tor tor [.] tor_addr_is_null
```
The top `smartlist_remove()` comes from:
```
- smartlist_remove
- 11.10% smartlist_subtract
router_choose_random_node
choose_good_middle_server
onion_extend_cpath
onion_populate_cpath
circuit_establish_circuit
- circuit_launch_by_extend_info
- 10.93% launch_rendezvous_point_circuit
```
Amazingly enough, we spend more time selecting path than doing crypto on a service that gets DDoS by introduction requests (#29607).
There aren't many straight forward approach here. Optimizing the code path bits by bits could be an approach. Most likely, our first step is to have a benchmark for our current path selection code and try to improve on it incrementally.
There are also more hackish approach like pre-building a list of RP nodes at each consensus (or when torrc options are changed like `ExcludeNodes`) and then randomly picking nodes from there would go faster because they wouldn't need to go through long iterations of tests, it would be already done.
One example is `router_choose_random_node()` that goes over the entire nodes list just to pick nodes to exclude, then again to test each nodes `router_add_running_nodes_to_smartlist()` and then potentially does a series of `smartlist_subtract()` that iterate over the entire list again. This is in theory `O(n) + O(n) + O(n)` actually theoretically being `O(n)` but reality is far from the theory here in CPU consumption ;).Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30221HS performance optimizations of codebase (master ticket)2020-06-13T15:52:34ZGeorge 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/legacy/trac/-/issues/30220Consider proof-of-rendezvous as a way to decrease INTRODUCE2 flood2020-06-13T15:40:51ZGeorge KadianakisConsider proof-of-rendezvous as a way to decrease INTRODUCE2 floodTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29999Objective 1, Activity 2: Denial of service defences2020-06-13T15:40:11ZPili GuerraObjective 1, Activity 2: Denial of service defencesThis is the parent ticket to hold any tickets under this activity, including:
- Reducing the amount of circuits that they build over time on the Tor network
- Providing more ways for onion service administrators to control the influx of ...This is the parent ticket to hold any tickets under this activity, including:
- Reducing the amount of circuits that they build over time on the Tor network
- Providing more ways for onion service administrators to control the influx of incoming users in heavy traffic scenarios.
- Improving our defense mechanisms by:
- Decreasing onion service load on the Tor network, by slowing down Tor circuit creation on startup.
- Optimizing relevant onion service functions that are called multiple times therefore taking a lot of the CPU.
- Making it harder for adversaries to force services to rotate their introduction points.
- Writing a Tor software change proposal for a “rendezvous approver” API that can be useful for:
1. Rate limiting; allow at most N unauthenticated clients over a set time period
2. Extra-conservative logic like "stop accepting connections during potential guard discovery"
3. Limiting capacity to control server load; only allow N simultaneous clients.
4. Protocol-tuned rules for things like Ricochet
5. More advanced pre-rendezvous authorization
6. Load-balancing across multiple servers running Tor onion services
- Closing client circuit once the INTRO1/ACK dance has been completed, decreasing load on the Tor network.Tor: unspecified