| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Now that we no longer respond to DESTROY by sending a DESTROY ourselves,
these tests need to be updated.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
constructor
Replaces `TryFrom<SubprotocolRequest> for HandshakeSubprotocols`.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
tor-proto: Small improvements to circuit handshake tests
See merge request tpo/core/arti!4254
|
| | |
| |
| |
| |
| | |
Now that we read all of the cells from the connection inspector, we can
reuse the existing channel objects.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
These TODOs are for client issues, not relay isues.
|
| | |
| |
| |
| | |
Otherwise the new circuit gets closed immediately by the relay.
|
| |\ \
| |/
|/|
| |
| | |
tor-protover,tor-proto: Add and use a new `subprotocol_restricted_set` macro
See merge request tpo/core/arti!4241
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
`HopSettings::from_handshake_params()` checks that the parameters are
correct, so if there are invalid parameters we should fail early before
we initialize the `CryptStatePair`.
|
| | |
| |
| |
| | |
This is just to make ntor and CREATE_FAST handshakes consistent.
|
| |/ |
|
| |
|
|
|
|
| |
The advantage of this over using a `SubprotocolRequest` is that we can
use the type system to ensure it only has subprotocols that are allowed
during a handshake.
|
| |
|
|
|
| |
We never used this, it was just needed because we used to convert to a
`CircParameters` which required this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... and also remove `CircNetParameters::as_circ_parameters()`.
We used to call `HopSettings::from_params_and_caps()` when handling
incoming circuit requests, but this didn't really make sense because we
already know exactly what settings we want.
The new `HopSettings::from_handshake_params()` takes the exact settings
we want, which means we can also skip constructing a `CircParameters`
and use the raw consensus `CircNetParameters`.
Most of the code in `CircNetParameters::as_circ_parameters()` has been
migrated in some form to `HopSettings::from_handshake_params()`.
|
| | |
|
| |
|
|
|
| |
As suggested in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4222#note_3437129
|
| |
|
|
| |
Applies @opara's suggested rephrasing.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
We need to return the "futures::Stream of Tor streams" from the CREATE
handler, because these need to be handled from `arti-relay`,
as per `doc/dev/notes/relay-streams.md`
This commit is intentionally (slightly) misformatted to make reviewing a
bit easier (the next commit will rustfmt everything).
Part of #2612
|
| |
|
|
|
| |
The inner type is an eyesore, and doesn't really need to be exposed
outside of tor-proto (we might even replace it at some point).
|
| |
|
|
|
|
|
|
| |
The `CreateRequestHandler` now passes the list of allowed "incoming
stream request" commands (i.e. BEGIN, BEGIN_DIR, or RESOLVE) to the
reactor, replacing the hard-coded command list.
Closes #2606
|
| |
|
|
|
|
|
|
|
|
|
| |
This enables us to make these configurable: any relays that are not
configured to be an exit will exclude BEGIN and RESOLVE from their list
of allowed commands, causing exit and DNS streams to be rejected as soon
as the BEGIN/RESOLVE cell is received in the circuit reactor.
Context: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4145#note_3430345
Part of #2606
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements what we discussed in
`doc/dev/notes/relay-streams.md` (lines 218-234):
> Currently, to allow incoming stream requests on a circuit,
> you first need to call `RelayCirc::allow_stream_requests()`
> to install a `CmdChecker` and `IncomingStreamRequestFilter`.
> This is not ideal, because `allow_stream_requests()` will need to be
> called unconditionally, on each `RelayCirc`,
> right after it's created in the `CreateHandler` impl
> (which in turn, would mean making `handle_create()` async too,
> because `allow_stream_requests()` is async, which wouldn't be great).
>
> So, the first step here is to rework the `RelayCirc` API to make relay circuits
> be constructable with a list of allowed `RelayCmd`s and `IncomingStreamRequestFilter`
> from the get-go ([#2582]), and to get rid of `allow_stream_requests()`,
> which will enable the `CREATE*` handler to remain non-`async`.
>
> In any case, the `CREATE*` handler will still require some changes,
> because it needs to be initialized with an `IncomingStreamRequestFilter`,
I am not sure using an `IncomingStreamRequestFilter` "factory" is
necessarily the right approach here, but the circuit `Reactor`'s
constructor needs to take an `IncomingStreamRequestFilter`, and
`IncomingStreamRequestFilter` is not `Clone` (and FWIW, I think it's
better if we don't make it `Clone`).
One obvious limitation is that the `IncomingStreamRequestFilter` of the
circuit reactor is fixed for the entire lifetime of the circuit.
In practice, I don't think this is going to be a problem,
because the arti-relay `IncomingStreamRequestFilter` is only going
be used for
* preventing single-hop exit streams
* per-circuit rate-limiting.
Both of these checks will require the filter to have access to a recent
`NetDir`, which is straightforward if the filter has an Arc<dyn
NetDirProvider> (as mentioned in doc/dev/notes/relay-streams.md,
`NetDirProvider` has a handy non-async `timely_netdir()` function we can
use). And since these checks are based on consensus params, we don't
really need to ever update an already-built circuit with a new
`IncomingStreamRequestFilter` (because all `IncomingStreamRequestFilter`
will have the ability to obtain a fresh `NetDir` as needed).
Nevertheless, I left a TODO about this, because I expect this type to
change once we figure out all the other pieces needed for #1448.
|
| |
|
|
| |
Part of #2582
|
| |
|
|
|
|
|
|
|
| |
Relay circuits always need a filter, so it's best to set it via the
constructor.
Part of #2582
Closes #2577
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This is needed for relays as part of #2490.
Note that changing this type affects the client implementation too (i.e.
clients will start prioritizing inbound DESTROY, discarding any queued
data without forwarding it to their local streams). But that's okay,
because it will generally only affect misbehaving clients, and clients
unlucky enough to encounter a hibernating relay.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
This will be needed for ntor handshakes.
|
| |
|
|
|
|
|
|
|
| |
We can't access `NetParameters` in this crate to build from consensus
default value so instead add a `defaults_for_tests()` gated function for
each parameters object which puts in the defaults from the spec.
We'll need CircNetParameters in order to build create request handler
for unit tests hence why it is in src/circuit.rs.
|
| |
|
|
| |
This will be needed for ntor handshakes.
|
| | |
|
| |
|
|
|
| |
This also updates the key rotation task to call the setter whenever the
ntor keys get updated.
|
| |
|
|
| |
This will need to be updated each time the ntor keys change.
|
| |
|
|
|
| |
Clippy has started warning about this since we moved the CREATE_FAST
handling to a helper, so this resolves that.
|
| | |
|
| | |
|
