Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2022-03-22T13:12:44Zhttps://gitlab.torproject.org/legacy/trac/-/issues/15516Consider rate-limiting INTRODUCE2 cells when under load2022-03-22T13:12:44ZJohn BrooksConsider rate-limiting INTRODUCE2 cells when under loadIn #15463, we're seeing an effective denial of service against a HS with a flood of introductions. The service falls apart trying to build rendezvous circuits, resulting in 100% CPU usage, many failed circuits, and impact on the guard.
...In #15463, we're seeing an effective denial of service against a HS with a flood of introductions. The service falls apart trying to build rendezvous circuits, resulting in 100% CPU usage, many failed circuits, and impact on the guard.
We should consider dropping INTRODUCE2 cells when the HS is under too much load to build rendezvous circuits successfully. It's much better if the HS response in this situation is predictable, instead of hammering at the guard until something falls down.
One option is to add a HSMaxConnectionRate(?) option defining the number of INTRODUCE2 we would accept per 10(?) minutes, maybe with some bursting behavior. It's unclear what a useful default value would be.
We could try to use a heuristic based on when rend circuits start failing, but it's not obvious to me how that would work.Tor: unspecifiedDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/296072019 Q1: Denial of service on v2 and v3 onion service2022-03-22T13:12:44ZTrac2019 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/legacy/trac/-/issues/24902Denial of Service mitigation subsystem2022-03-17T19:41:32ZDavid Gouletdgoulet@torproject.orgDenial of Service mitigation subsystemThis ticket is for adding a denial of service mitigation subsystem to tor.
Because of the latest issues we've been having on the network with 1 million users most likely resulting in the huge loads on the relays we've been seeing, this ...This ticket is for adding a denial of service mitigation subsystem to tor.
Because of the latest issues we've been having on the network with 1 million users most likely resulting in the huge loads on the relays we've been seeing, this subsystem is to provide a framework in order to add defense to tor for potential (voluntary or not) denial of service.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://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/17254Scalable HSes by splitting intro/rendezvous2020-06-13T15:52:34ZTvdWScalable HSes by splitting intro/rendezvousasn suggested creating a ticket before the proposal is committed, so here I go.
Most relevant mail from the thread (contains the proposal): https://lists.torproject.org/pipermail/tor-dev/2015-October/009625.htmlasn suggested creating a ticket before the proposal is committed, so here I go.
Most relevant mail from the thread (contains the proposal): https://lists.torproject.org/pipermail/tor-dev/2015-October/009625.htmlTor: unspecifiedTvdWTvdWhttps://gitlab.torproject.org/legacy/trac/-/issues/26294attacker can force intro point rotation by ddos2020-06-13T15:52:34ZRoger Dingledineattacker can force intro point rotation by ddosCurrently, an onion service's intro points each expire (intentionally rotate) after receiving rand(16384, 16384*2) intro requests.
Imagine an attacker who generates many introduction attempts. Since each intro attempt can take its own p...Currently, an onion service's intro points each expire (intentionally rotate) after receiving rand(16384, 16384*2) intro requests.
Imagine an attacker who generates many introduction attempts. Since each intro attempt can take its own path to the target intro point, the bottleneck will be the introduction circuit itself. Let's say that intro circuit can sustain 500KBytes/s of traffic. That's 1000 intro requests per second coming in -- so after 24ish seconds (rand(16,32)), that intro point will expire: the onion service will pick a new one and start publishing new onion descriptors.
If the intro circuit can handle 1MByte/s, then rotation will happen after 12ish seconds.
With three intro circuits, each receiving intro requests at a different rate, we could end up changing our descriptor even more often than this. There are at least four impacts from this attack:
(1) Onion services spend energy and bandwidth generating new intro circuits, and publishing new descriptors to list them.
(2) Clients might get the last onion descriptor, not the next one, and so they'll attempt to introduce to a circuit that's no longer listening.
(3) The intro points themselves get a surprise 16k-32k incoming circuits, probably plus a lot more after that because the attacker wouldn't know when to stop. Not only that, but for v2 onion services these circuits use the slower TAP as the circuit handshake at the intro point.
(4) The HSDirs get a new descriptor every few seconds, which aside from the bandwidth and circuit load, tells them that the onion service is under attack like this.
Intro points that can handle several megabytes of traffic per second will keep up and push the intro requests back to the onion service, thus hastening the rotation. Intro points that *can't* handle that traffic will become congested and no fun to use for others during the period of the attack.
The reason we rotate after 16k-32k requests is because the intro point keeps a replay cache, to avoid ever responding to a given intro request more than once.
One direction would be to work on bumping up the size of the replay cache, or designing a different data structure like a bloom filter so we can scale the replay cache better. I think we could succeed there. The benefits would be to (1) and (2) and (4) above, i.e. onion services won't spend so much time making new descriptors, and clients will be more likely to use an onion descriptor that's still accurate. The drawback would be to (3), where the hotspots last longer, that is, the poor intro point feels the damage for a longer period of time.
Taking a step back, I think there are two directions we can go here. Option one, we can try to scale to handle the load. We would focus on load balancing better, like reacting to an attack by choosing super fast intro points, and either choosing fast middle nodes too, or some fancier approach like having multiple circuits to your intro point. Option two, we recognize that this volume of introduction requests represents a problem in itself, and try to introduce defenses at the intro point level. Here we focus on proof of work schemes or other ways to slow down the flow, or we improve the protocol to pass along hints about how to sort the intro requests by priority.Tor: unspecifiedGeorge KadianakisGeorge Kadianakishttps://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/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/24964dos: Block single hop client at the HSDir2020-06-13T15:46:21ZDavid 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 #24902.This is so we remove load from spammy tor2web clients at the HSDir level.
Opened after discussion in #24902.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24962Single hop onion service denial of service issues2020-06-13T15:45:38ZDavid Gouletdgoulet@torproject.orgSingle hop onion service denial of service issuesThis is a parent ticket for all single hop anti-DoS mitigation we want to put in Tor. Not only that but it should be seen as "any client single hop" hidden service requests rather than tor2web specific.
Child tickets are really the meat...This is a parent ticket for all single hop anti-DoS mitigation we want to put in Tor. Not only that but it should be seen as "any client single hop" hidden service requests rather than tor2web specific.
Child tickets are really the meat of the work so anything related to this topic should have a child ticket and this parent ticket should not be used for discussions.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://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: unspecified