| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This cell should be treated as invalid for purposes of CIRC_BW.
|
|
Should prevent other bugs like 26117.
|
|
Previously, we used the AF_UNSPEC check to represent valid connected cell
data as a result of the lack of return. This was incorrect.
|
|
|
|
|
|
|
|
|
|
Fixes bug 26072; bugfix on 0.2.4.7-alpha.
|
|
|
|
|
|
Two new values in each direction. DELIVERED counts valid end-to-end circuit
data that is accepted by our end and OVERHEAD counts the slack unused data in
each of the relay command cells for those accepted cells.
Control port changes are in the next commit.
|
|
|
|
|
|
|
|
We recently merged a circuit cell queue size safeguard. This commit adds the
number of killed circuits that have reached the limit to the DoS heartbeat. It
now looks like this:
[notice] DoS mitigation since startup: 0 circuits killed with too many
cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0
single hop clients refused.
Second thing that this patch does. It makes tor always print the DoS
mitigation heartbeat line (for a relay) even though no DoS mitigation have
been enabled. The reason is because we now kill circuits that have too many
cells regardless on if it is enabled or not but also it will give the operator
a chance to learn what is enabled with the heartbeat instead of suddenly
appearing when it is enabled by let say the consensus.
Fixes #25824
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
There are quite a few other places this could be used, but keeping it simple
for now.
|
|
|
|
|
|
This commit introduces the consensus parameter "circ_max_cell_queue_size"
which controls the maximum number of cells a circuit queue should have.
The default value is currently 50000 cells which is above what should be
expected but keeps us a margin of error for padding cells.
Related to this is #9072. Back in 0.2.4.14-alpha, we've removed that limit due
to a Guard discovery attack. Ticket #25226 details why we are putting back the
limit due to the memory pressure issue on relays.
Fixes #25226
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
* ADD new /src/common/crypto_rand.[ch] module.
* ADD new /src/common/crypto_util.[ch] module (contains the memwipe()
function, since all crypto_* modules need this).
* FIXES part of #24658: https://bugs.torproject.org/24658
|
|
|
|
Next commit is addressing the circuit queue cell limit so cleanup before doing
anything else.
Part of #25226
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
This should help us improve modularity, and should also make it
easier for people to experiment with other relay crypto strategies
down the road.
This commit is pure function movement.
|
|
|
|
This function is used upon receiving a cell, and only handles the
decrypting part. The encryption part is currently handled inside
circuit_package_relay_cell.
|
|
|
|
|
|
|
|
|
|
The reason to do so is because these functions haven't been used in years so
since 0.2.4, every callsite is NOP.
In future commits, we'll remove the round robin circuit policy which is mostly
validated within those function.
This simplifies the code greatly and remove dead code for which we never had a
configure option in the first place nor an easy way to use them in production.
Part of #25268
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
If the cache is using 20% of our maximum allowed memory, clean 10% of it. Same
behavior as the HS descriptor cache.
Closes #25122
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
connection_t.timestamp_lastwritten renamed to
connection_t.timestamp_last_write_allowed
connection_t.timestamp_lastread renamed to
connection_t.timestamp_last_read_allowed
Closes ticket 24714.
|
|
We'd been using crypto_digest_dup() and crypto_digest_assign() here,
but they aren't necessary. Instead we can just use the stack to
store the previous state of the SHA_CTX and avoid a malloc/free pair.
Closes ticket 24914.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This way it will match the insert queue in 029 and later.
|
|
|
|
|
|
We've been seeing problems with destroy cells queues taking up a
huge amount of RAM. We can mitigate this, since while a full packed
destroy cell takes 514 bytes, we only need 5 bytes to remember a
circuit ID and a reason.
Fixes bug 24666. Bugfix on 0.2.5.1-alpha, when destroy cell queues
were introduced.
|
|
Exposing cell_queues_get_total_allocation(), buf_get_total_allocation(),
tor_compress_get_total_allocation(), tor_compress_get_total_allocation() when
hit MaxMemInQueues threshold.
Fixes #24501
Signed-off-by: Fernando Fernandez Mancera <ffernandezmancera@gmail.com>
|
|
|
|
|
