Please note:
Here parameter DoSCircuitCreationMinConnections=1 is set (rather than the default value of 3).
Mar 11 17:23:53 Tor[]: DoS mitigation since startup: 0 circuits rejected . . . . . . Mar 22 11:23:54 Tor[]: DoS mitigation since startup: 299608 circuits rejected. . . Mar 22 17:23:54 Tor[]: DoS mitigation since startup: 806025 circuits rejected. . .
I.E. mitigation circuit rejections increased 170% in six hours after moving vaguely for over ten days.
Also:
top - 19:05:53 up 11 days. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1998 tor 20 0 662m 611m 108m R 47.2 15.4 7901:32 tor 2000 tor 20 0 662m 611m 108m S 42.2 15.4 343:28.28 tor 2001 tor 20 0 662m 611m 108m R 56.8 15.4 343:24.46 tor
I.E. crypto workers pegged after barely registering since DoSer shut it down on March 7th.
'iptables' mitigation rule here shows the DoS source-IPs ablaze.
==========
Suggestion: DoSCircuitCreationMinConnections=1 be established in consensus
Suggestion: DoSCircuitCreationMinConnections=1 be established in consensus
The man page for the above option says:
"Minimum threshold of concurrent connections before a client address can be flagged as executing a circuit creation DoS. In other words, once a client address reaches the circuit rate and has a minimum of NUM concurrent connections, a detection is positive. "0" means use the consensus parameter. If not defined in the consensus, the value is 3. (Default: 0)"
Reading this, I get the impression that lowering the value to 1 would negatively impact clients behind carrier NAT. Isn't that the case? If we only allow 1 concurrent connection per IP, wouldn't that prevent multiple users behind a single IP? I would think the same problem would apply to lowering DoSConnectionMaxConcurrentCount as well (which I think is currently 50 in the consensus, but I've seen suggestions to lower it to 4).
Am I misunderstanding?
On 22 Mar (23:20:54), tor wrote:
Suggestion: DoSCircuitCreationMinConnections=1 be established in consensus
The man page for the above option says:
"Minimum threshold of concurrent connections before a client address can be flagged as executing a circuit creation DoS. In other words, once a client address reaches the circuit rate and has a minimum of NUM concurrent connections, a detection is positive. "0" means use the consensus parameter. If not defined in the consensus, the value is 3. (Default: 0)"
Reading this, I get the impression that lowering the value to 1 would negatively impact clients behind carrier NAT. Isn't that the case? If we only allow 1 concurrent connection per IP, wouldn't that prevent multiple users behind a single IP? I would think the same problem would apply to lowering DoSConnectionMaxConcurrentCount as well (which I think is currently 50 in the consensus, but I've seen suggestions to lower it to 4).
Am I misunderstanding?
Yes, lowering DoSCircuitCreationMinConnections=1 means that you only need 1 concurrent client TCP connection to start applying the circuit creation DoS mitigation instead of 3 concurrent. This will thus impact all type of clients and *especially* hidden services which have many clients. They will open many circuits in few seconds so making your Guard apply DoS mitigation will make them sad.
I would strongly suggest to leave it untouched in your option file for now and let the consensus value being used.
Thanks! David
At 03:20 3/23/2018 +0000, tor tor@anondroid.com wrote:
Suggestion: DoSCircuitCreationMinConnections=1 be established in consensus
The man page for the above option says:
"Minimum threshold of concurrent connections before a client address can be flagged as executing a circuit creation DoS. In other words, once a client address reaches the circuit rate and has a minimum of NUM concurrent connections, a detection is positive. "0" means use the consensus parameter. If not defined in the consensus, the value is 3. (Default: 0)"
[snip]
Am I misunderstanding?
"concurrent connections" refers to concurrent TCP+TLS network layer connections, not to Tor circuits--nominally one-connection-per-peer IP. It means the excess circuit-extend rate logic does not kick in at all until at least N TCP connections from a particular IP exist. Once the configured number of TCP connections is present, the circuit extend rate is examined.
An adversary who stays under the configured limit (presently three) can extend circuits at extreme rates on (two) TCP connections. Adversary must marshal a larger number of IP addresses than previously to obtain the same effect and this raises the cost of attack, but they may still cause significant trouble as my relay's statistics demonstrate.
tor-relays@lists.torproject.org
-
David Goulet -
starlight.2017q4＠binnacle.cx -
tor