| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
When the circ-padding feature is enabled, we use maybenot, which does
not yet support rand 0.10. In the meantime, enabling this feature pulls
in rand 0.9. This is not ideal, but should be okay as a temporary
situation.
This also replaces the use of ReseedingRng (which was removed in 0.10)
with the reseeding_rng crate. This is somewhat less performant, but it
should be okay.
|
| |
|
|
| |
"Stored" is more accurate than "current".
|
| |
|
|
|
|
|
| |
The blinded HsIds were used a proxy for the time periods, but it's
better to just compare the TPs directly.
Part of #966
|
| | |
|
| |
|
|
| |
This will soon need to be copied into `HsDescForTp`.
|
| |
|
|
|
|
| |
We no longer consider the HsDir rate-limited if its `requery == now`.
This was caught by the new tests.
|
| | |
|
| | |
|
| |
|
|
|
| |
This needs to be dropped before the next test (because the test will try
to acquire the lock inside the `Mocks` impl).
|
| | |
|
| |
|
|
|
|
| |
We need to build this twice per test (because keypairs aren't `Clone`).
I find that putting boilerplate like this in a separate function makes
the tests more legible.
|
| |
|
|
|
| |
I'm trying to reduce the cognitive load of the test a bit, because I
will soon extend it so it will grow even more complex.
|
| | |
|
| |
|
|
| |
I find very long paths a bit hard to read..
|
| |
|
|
| |
The line the comment is referring to for no longer exists.
|
| |
|
|
| |
To ensure it's actually `Ok(())` like we expect.
|
| | |
|
| | |
|
| |
|
|
| |
`connect()` no longer panics, so we don't need it anymore.
|
| | |
|
| |
|
|
|
| |
Doing this means we wont't need to go through the trouble of building a
valid `Rendezvous2` cell in the tests.
|
| |
|
|
|
| |
This is used, and is getting in the way a little bit, so I am removing
it.
|
| |
|
|
|
|
|
| |
If the blinded id has changed since we cached our descriptor, it means
the TP has changed, and so we can assume the new descriptor is fresher.
Part of #966
|
| |
|
|
|
|
| |
This enables us to tell whether a newly fetched descriptor's revision
counter can be compared with the revision counter of our cached
descriptor.
|
| |
|
|
| |
C Tor calls this a "period", but "interval" is more accurate.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
As David mentioned in a review comment, we don't want to refetch the
descriptor unless *all* introduction attempts have failed. See
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3925#note_3402810
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the client doesn't have a timely cached descriptor, then ignore
the requery period and reach out to all the HsDirs of the service.
This can, in theory, cause the client to unnecessarily query the HsDirs
when its cached descriptor has expired, but this would be a very rare
event, because the descriptor is long lived.
I'm carving out this exception to the usual rate-limiting behavior,
because I suspect having the client more eagerly reattempt the
connection will be better for UX, (by the time the client's descriptor
expires, the service, assuming it's still online, is expected to have
published a new one, so IMO it makes sense to try to fetch it).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Because we now refetch HsDirs on introduce NACK, we need some type of
rate-limiting to prevent clients from hammering the HsDirs if the
service is offline.
This rate-limiting is per-HsDir: the client will avoid querying the
same HsDir more frequently than `hs_dir_requery_period`. The HsDir
requery info is stored in the new `DataHsDirs` map.
Part of #966
|
| | |
|
| |
|
|
| |
This is no longer an `&OwnedChanTarget`, so I'm renaming it accordingly.
|
| |
|
|
|
|
|
| |
The new `RelayIdFor` type alias I'm about to add will need to call
`RelayIdFor::{for_lookup, for_store}` with a type that isn't
`&OwnedChanTarget`, so I will need these functions to take a generic
`HasRelayIds`.
|
| |
|
|
|
|
|
|
| |
This refactors `RelayIdForExperience` into a more generic `RelayIdFor`
type.
`RelayIdFor` will serve the basis for another key type that will be used
for storing `HsDir` information.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
I find having too many of these nested `else { None }` branches makes
the overall logic harder to follow, so I changed this to use `Option<>`
combinators instead.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This avoids us replacing our cached hsdesc with one that has a lower
revision counter.
This was not a problem before, because we'd only ever fetch a new
descriptor when our cahced one expired, but now that we refetch the
descriptor on introduction NACK, we need to make sure the new descriptor
is actually more recent than the one we have.
The implementation is a bit convoluted because I had to avoid retaining
a reference to the known-timely cached `desc` so as not to anger borrowck.
|
| |
|
|
| |
This will soon need to be called from two places, unfortunately.
|
| | |
|
| |
|
|
|
| |
As suggested in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3925?commit_id=22ae30205a5f18fee43f424f8c0f9768b95a2ae6#note_3402779
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this change, arti clients would retain their cached HS
descriptors until expiry. This is causing us some problems in
[arti#2458], where arti frequently fails to connect to C Tor services
in a chutney test net. One of the problems in #2458 is that all
introduction points are NACK-ing the client's introduction requests,
ultimately causing the connection attempt to fail:
```
2026-04-23T16:25:23Z DEBUG tor_hsclient::state: HS connection failure for ijalr3vpf67zradtlaxze6pex5ypadu5qfsltn42cmhioqory6363tad.onion error=error: Unable to connect to hidden service using any Rendezvous Point / Introduction Point: Tried to make circuit to hidden service 6 times, but all attempts failed
Attempt 1: Introduction point #3 reported error in its INTRODUCE_ACK: NOT_RECOGNIZED
Attempt 2: Introduction point #2 reported error in its INTRODUCE_ACK: NOT_RECOGNIZED
Attempt 3: Introduction point #1 reported error in its INTRODUCE_ACK: NOT_RECOGNIZED
Attempt 4: Introduction point #3 reported error in its INTRODUCE_ACK: NOT_RECOGNIZED
Attempt 5: Introduction point #2 reported error in its INTRODUCE_ACK: NOT_RECOGNIZED
Attempt 6: Introduction point #1 reported error in its INTRODUCE_ACK: NOT_RECOGNIZED
```
I think this is happening because the C Tor service has rotated intro
points and republished its descriptor, before the descriptor's planned
expiry. I believe is something that can (and does) happen, and so arti
should be able to handle it gracefully.
I added some more logs to arti and reran the test, and noticed the
descriptor's lifetime works out to be just over 2 days (54h), which
seems excessive (especially in our test net, where the voting interval
is 20s and the hsdir interval is 8min). In any case, holding on to a
service's descriptor for too long, and not refetching a new one, will
cause the client's introduction requests to be rejected (because the
service might switch intro points).
I think there are at least 2 things we need to do to improve arti's
handling of HS connections:
* In the case of an introduce NACK (with status = `NOT_RECOGNIZED`),
the client should refetch the descriptor and then retry the
introduction. This behavior is not codified in the spec yet (see
torspec#245), but I am told this is what C Tor does
* Rethink the cached descriptor expiry calculation
This commit addresses the first point. The second one seems trickier, so
I have not looked into it yet.
Part of #966
[arti#913]: https://gitlab.torproject.org/tpo/core/arti/-/work_items/913#note_2914448
[arti#2458]: https://gitlab.torproject.org/tpo/core/arti/-/work_items/2458#note_3400768
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This will soon be used to force a refetch in the case of an
`INTRODUCE_NACK`.
(This commit is intentionally left misindented to make reviewing a bit
easier. A future commit will rustfmt the file).
|
| |
|
|
|
|
|
| |
Gabi correctly points out that since the client uses guarded
circuits for introduction points, whereas the service uses naive
circuits, we shouldn't expect the peer's circuits to be any longer
than ours.
|
| |
|
|
|
|
|
|
|
| |
Both C tor and Arti will retry building a circuit if the first
attempt fails. This means that it can be worthwhile waiting longer
than we might otherwise for the HS to build its rendezvous circuit.
We don't need to make this change for _our_ circuits, since
the CircMgr code takes care of those timeouts for us.
|