Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
Fixes #40932
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
It turns out that circuit_package_relay_cell() returns 0 in order to drop a
cell but there is a code path, if the circuit queue is full, that also silently
closes the circuit and returns 0.
This lead to Conflux thinking a cell was sent but actually the cell was not and
the circuit was closed leading to the hard assert.
And so this function makes sure that circuit_package_relay_cell() and
append_cell_to_circuit_queue() returns a value that indicate what happened with
the cell and circuit so the caller can make an informed decision with it.
This change makes it that we do NOT enter the Conflux subsystem if the cell is
not queued on the circuit.
Fixes #40921
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Make two 1-bit fields unsigned
Closes #40911
See merge request tpo/core/tor!796
|
|
This should be a completely harmless warning as we only check whether
the fields are true or false.
Closes #40911.
|
|
This commit adds the total number of DROP cell seen, the total number of
DESTROY cell received and the total number of protocol violation that lead to a
circuit close.
Closes #40816
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
|
|
We strongly suspect that bug 40897 was caused by a custom Tor client that
tried to use more than the default number of conflux circuits, for either
performance or traffic analysis defense gains, or both.
This entity hit a safety check on the exit side, which caused a UAF. Our
"belt and suspenders" snapped off, and hit us in the face... again...
Since there are good reasons to try more than 2 conflux legs, and research has
found some traffic analysis benefits with as many as 5, we're going to raise
and parameterize this limit as a form of bug bounty for finding this UAF, so
that this entity can try out a little more confluxing.
This should also make it easier for researchers to try things like gathering
traces with larger amounts of confluxing than normal, to measure real-world
traffic analysis impacts of conflux.
Shine on, you yoloing anonymous diamond. Let us know if you find out anything
interesting!
|
|
Similar double-frees would be caught earlier by these, so long as the pointers
remain nulled out.
|
|
|
|
|
|
For vanguards addon.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
conflux: Flag set as in full teardown in the free path
Closes #40870
See merge request tpo/core/tor!777
|
|
We suspect a shutdown race of some sort for which the full teardown is not
noticed during the close but should be during the free.
For that, we flag the conflux set as in full teardown (if so) in the free path
in case the close path didn't caught it.
Fixes #40870
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
This issue was originally called out by pseudonymisaTor on !707; the comment in
this commit takes a different approach to explaining what is going on.
|
|
|
|
|
|
Just in case there are other instances hiding in the maze.
|
|
|
|
|
|
reapply exit policy on reload
Closes #40676
See merge request tpo/core/tor!735
|
|
Also add more info to leg dump.
|
|
HTML in comment, what a bad idea...
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
This reverts commit 5487476fd919703b55cb1f1544d575224c9b685e.
|
|
This exemption used to be helpful in keeping exit relays from tripping
the DoS detection subsystem and losing Tor connectivity. Now exit relays
block re-entry into the network (tor issue #2667) so it's no longer
needed. We'd like to re-enable protection on these addresses to avoid
giving attackers a way around our DoS mitigations.
|
|
tor only marks a channel as 'open' once the TLS and OR handshakes have both
completed, and normal "client" (ORPort) DoS protection is not enabled until
the channel becomes open. This patch adds an additional earlier initialization
path for DoS protection on incoming TLS connections.
This leaves the existing dos_new_client_conn() call sites intact, but adds a
guard against multiple-initialization using the existing
tracked_for_dos_mitigation flag. Other types of channels shouldn't be affected
by this patch.
|
|
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|