| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
During the channel handshake, we require the peer IP address for the
canonicity check which requires the exact peer IP we are connected to.
This commit adds a function that enforces this requirement on a
ChannelMethod so anything else results in an error.
It is to basically have stronger guarantee on the channel method we use
in the handshake.
Signed-off-by: David Goulet <[email protected]>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
When connecting, we pass an OwnedChanTarget that can contain a list of
IPs of the relay we want to connect to. The connect() picks one and
return the actual OwnedChanTarget used as in the real IP address we are
using.
From that point on, we must only use that as the channel canonicity
requires to check against the IP we believe we are connected to.
This also is much better to use for error handling considering the error
is on the actual channel target, not the hypothetical one.
Signed-off-by: David Goulet <[email protected]>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
All handshake pass the NETINFO cell, the advertised addresses (if any)
and the peer address in order to build the Canonicity and build the
channel with it.
In order to pull this off, the "my_addrs" were added to several object
along the NETINFO cell.
We also pass the channel method when connecting (initiator) to a relay
as we need this for this canonicity build.
Signed-off-by: David Goulet <[email protected]>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This struct will be put in a Channel and derived from the received
NETINFO cell.
This follows the C-tor implementation for which we have two indicator of
canonicity:
1. Peer is canonical: the address they advertise in the NETINFO cell
matches the one we see on the TCP connection.
2. Canonical to peer: the peer sees us as canonical.
Those flag will get used to select "the best" channel.
Signed-off-by: David Goulet <[email protected]>
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
proto: Return internal error on TRUNCATE
See merge request tpo/core/arti!3675
|
| | |/ / / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This is not yet implemented, so we should just return an error for now
(`todo!()` will cause a panic, shutting down the thread the reactor is
running on. We don't want this happening when we start manually testing
our WIP impl, because depending on which thread it happens on, it can
make the entire relay process unusable).
|
| |\ \ \ \ \ \ \
| |/ / / / / /
|/| | | | | |
| | | | | | |
| | | | | | | |
tor-chanmgr: Add `HasAddrs` bound to `AbstractChannelFactory::BuildSpec`
See merge request tpo/core/arti!3673
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
We will want our channel selection functions (`open_channel_is_allowed`,
`pending_channel_maybe_allowed`, and `choose_best_channel`) to inspect
the requested target addresses in the future (see their TODOs), so these
functions need to take a `HasAddrs` to get those addresses.
|
| |/ / / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This will be needed later so that our channel selection functions can
take a `HasAddrs`.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
proto: Handle backward cells in the reactor
Closes #2345
See merge request tpo/core/arti!3666
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Closes #2345
|
| | | | | | | | |
|
| | | |/ / / /
| |/| | | |
| | | | | |
| | | | | | |
This will tell the base `BackwardReactor` how to handle the cell.
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
arti: Enable tor-hsservice/onion-service-cli-extra when needed
Closes #2347
See merge request tpo/core/arti!3670
|
| | | | | | | |
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Without this change `arti` fails to compile with the `onion-service-cli`
and `onion-service-service` features enabled.
Closes #2347
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
relay: Add the TLS acceptor to a ChanMgr
See merge request tpo/core/arti!3661
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Signed-off-by: David Goulet <[email protected]>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Signed-off-by: David Goulet <[email protected]>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Signed-off-by: David Goulet <[email protected]>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
A client can have the relay feature enabled. The presence of
"identities" is what dictates if we are a relay or not.
Signed-off-by: David Goulet <[email protected]>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Also, allow the `ChanMgr::runtime` to be unused as client don't use it
yet but might one day.
Simpler this way than feature gating it for relay only.
Signed-off-by: David Goulet <[email protected]>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Signed-off-by: David Goulet <[email protected]>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Implement the accept_from_transport() in the ChanBuilder.
This returns a `Channel` and spawns a reactor.
Signed-off-by: David Goulet <[email protected]>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This type is needed in the tor-chanmgr crate in order to decide to
verify or not the underlying relay channel.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This requires the `TlsKeyAndCert` so be passed on the TLS acceptor
settings. We assume that `RelayIdentities` has this information.
The ChanBuilder::new() was getting a bit too convoluted and feature
gated to instead we introduce new_client() and new_relay() and remove
the need for `with_identities()`.
Because of this, the ChanMgr::new() now returns a `Result<>`.
Related to #1597
Signed-off-by: David Goulet <[email protected]>
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This makes it that we can get a server TLS acceptor provider which we
need for incoming connections.
Signed-off-by: David Goulet <[email protected]>
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
downgrade-dependencies: require async-io 1.1.5.
Closes #1168
See merge request tpo/core/arti!3660
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In my testing, this appears to fix #1168, an intermittent test
failure. The underlying cause of the failure appears to be
a surprise blocking return old async-io versions:
> The problem was in that random yielding inside
> AsyncRead/AsyncWrite (which is supposed to prevent task starvation
> when I/O never returns the WouldBlock error) doesn't play nice
> with the TLS protocol. It seems that TLS handshake fails if a
> write errors with WouldBlock.
-- https://github.com/smol-rs/async-io/issues/31
I think the problem here might actually be something more subtle
than _that_, since WouldBlock on an underlying write is totally
legit. But this appears to fix the testing issue at least.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Set package.metadata.docs.rs.all-features to true for all crates
Closes #2307
See merge request tpo/core/arti!3656
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
All (publishable) crates should explicitly configure what features to (not) document in docs.rs.
This to avoid our documentation containing references to public API specifications which yield "given resource not found"
due to them being behind a feature flag not being published to docs.rs by default.
|
| | | |_|_|/ /
| |/| | | |
| | | | | |
| | | | | | |
Makes docs.rs also document types behind optional feature flags.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
proto: Start handling EXTEND2 in the relay reactor
Closes #1447
See merge request tpo/core/arti!3648
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
See discussion at
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3648#note_3339863
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Implements this part of the spec:
```
To tear down a circuit completely, a relay or client sends a DESTROY
cell to the adjacent nodes on that circuit, using the appropriate
direction’s circID.
```
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This doesn't need to be async, as it delegates the handling to a
background task.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
To handle EXTEND2, the relay `ForwardHandler` impl spawns a background
task, which reports back the result via the `CircEvent` MPSC stream.
This stream is polled from the `ForwardReactor` main loop, and each
`CircEvent` is passed back to `ForwardHandler::handle_event()` for
handling.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
These will be used by the relay code too (for circuit extension).
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Users reading the log won't necessarily know what a "forward channel" is.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This will enable us to obtain implementation-dependent asynchronous
events (such as the outcome of an extend handshake).
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This will be needed by relays, for wrapping tor_linkspec decode errors
(which can happen if the link specifiers in the EXTEND2 cell can't be
converted to a channel target).
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
To match the `ChannelProvider::get_or_launch()` function signature.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
We need the unique_id here, because the Forward handler will soon start
using the `ChannelProvider::get_or_launch()` to launch outbound
channels, which takes the reactor unique_id as an argument.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The channel provider is relay-specific, so I am moving it to the relay
`ForwardHandler` implementation. This enables us to get rid of some of
the feature gating from the generic reactor.
|