| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Just in case there are other instances hiding in the maze.
|
|
|
|
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>
|
|
Fix assert crash on relay-side due to on_circuit backpointer
See merge request tpo/core/tor!737
|
|
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This brings us into sync with the consensus, and will be useful for test
vectors, to ensure behavior consistent with the consensus params.
|
|
|
|
KISTSchedRunIntervalClient
|
|
Also, double check that the consensus has enough overall exits before
attempting conflux set launch.
|
|
|
|
Also add calls to dump the legs of a conflux set if we have too many
|
|
|
|
Otherwise, the BEGIN cell arrives at the exit before it has an RTT,
and then it does not know which circuit to prefer in response.
|
|
This will give us a full stacktrace.
|
|
|
|
|
|
|
|
This started as a response to ticket #40792 where Coverity is
complaining about a potential year 2038 bug where we cast time_t from
approx_time() to uint32_t for use in token_bucket_ctr.
There was a larger can of worms though, since token_bucket really
doesn't want to be using wallclock time here. I audited the call sites
for approx_time() and changed any that used a 32-bit cast or made
inappropriate use of wallclock time. Things like certificate lifetime,
consensus intervals, etc. need wallclock time. Measurements of rates
over time, however, are better served with a monotonic timer that does
not try and sync with wallclock ever.
Looking closer at token_bucket, its design is a bit odd because it was
initially intended for use with tick units but later forked into
token_bucket_rw which uses ticks to count bytes per second, and
token_bucket_ctr which uses seconds to count slower events. The rates
represented by either token bucket can't be lower than 1 per second, so
the slower timer in 'ctr' is necessary to represent the slower rates of
things like connections or introduction packets or rendezvous attempts.
I considered modifying token_bucket to use 64-bit timestamps overall
instead of 32-bit, but that seemed like an unnecessarily invasive change
that would grant some peace of mind but probably not help much. I was
more interested in removing the dependency on wallclock time. The
token_bucket_rw timer already uses monotonic time. This patch converts
token_bucket_ctr to use monotonic time as well. It introduces a new
monotime_coarse_absolute_sec(), which is currently the same as nsec
divided by a billion but could be optimized easily if we ever need to.
This patch also might fix a rollover bug.. I haven't tested this
extensively but I don't think the previous version of the rollover code
on either token bucket was correct, and I would expect it to get stuck
after the first rollover.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
|
|
|
|
|
|
|
|
|
|
|
|
Switch rate limiting will likely be helpful for limiting OOQ, but according to
shadow it was the cause of slower performance in Hong Kong endpoints.
So let's disable it, and then optimize for OOQ later.
|
|
Maxrate had slower throughput than lowrtt in Shadow, which is not too
surprising. We just wanted to test it.
|
|
This lets controller apps see the outgoing PoW effort on client
circuits, and the validated effort received on an incoming service
circuit.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
|
|
The goal of this patch is to add an additional mechanism for adjusting
PoW effort upwards, where clients rather than services can choose to
solve their puzzles at a higher effort than what was suggested in the
descriptor.
I wanted to use hs_cache's existing unreachability stats to drive this
effort bump, but this revealed some cases where a circuit (intro or
rend) closed early on can end up in hs_cache with an all zero intro
point key, where nobody will find it. This moves intro_auth_pk
initialization earlier in a couple places and adds nonfatal asserts to
catch the problem if it shows up elsewhere.
The actual effort adjustment method I chose is to multiply the suggested
effort by (1 + unresponsive_count), then ensure the result is at least
1. If a service has suggested effort of 0 but we fail to connect,
retries will all use an effort of 1. If the suggestion was 50, we'll try
50, 100, 150, 200, etc. This is bounded both by our client effort limit
and by the limit on unresponsive_count (currently 5).
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
|
|
We mark the intro circuit with a new flag saying that the pow is
in the cpuworker queue. When the cpuworker comes back, it either
has a solution, in which case we proceed with sending the intro1
cell, or it has no solution, in which case we unmark the intro
circuit and let the whole process restart on the next iteration of
connection_ap_handshake_attach_circuit().
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
At this commit, the tor main loop solves it. We might consider moving
this to the CPU pool at some point.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
