aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/relay
Commit message (Collapse)AuthorAgeFilesLines
...
* tor-proto: remove unnecessary `Option`sSteven Engler2026-02-241-12/+2
| | | | | | I don't think that the `Option`s are needed anymore, since unauthenticated channels no longer transition through the `VerifiedChannel` state.
* chanmgr: Don't allow to build relay channel to ourselfDavid Goulet2026-02-241-2/+12
| | | | | | | | | | The validate_relay_target() is meant to probably have more checks in the future hence the vagueness of it instead of being specific to the goal of this patch. Closes #1699 Signed-off-by: David Goulet <[email protected]>
* proto: Modify RelayIdentities to have encodable certDavid Goulet2026-02-231-13/+16
| | | | | | | This commit also adds the TlsKeyAndCert to the identities so the TLS acceptor can set it up. Signed-off-by: David Goulet <[email protected]>
* proto: Pass PeerAddr at the channel handshake finish for initiatorsDavid Goulet2026-02-194-18/+17
| | | | | | | | | | Responder relay handshake requires the peer address at the very start as it sends its NETINFO right away. For initiators, we only need it during the finalization process which is when the NETINFO is sent and the Channel is created. Signed-off-by: David Goulet <[email protected]>
* proto: Use the PeerAddr accross channel handshakeDavid Goulet2026-02-194-35/+33
| | | | | | | This is a large change but it is basically using PeerAddr in the channel builder through the channel handshake code and into the Channel itself. Signed-off-by: David Goulet <[email protected]>
* Merge branch 'relay-own-cert' into 'main'David Goulet2026-02-163-6/+20
|\ | | | | | | | | relay: Pass our TLS cert to the responder verify process See merge request tpo/core/arti!3665
| * relay: Pass our TLS cert to the responder verify processDavid Goulet2026-02-123-6/+20
| | | | | | | | | | | | | | | | | | | | For the responder to build the authentication data, it needs its own certificate of the TLS handshake that it is responding to (as a TLS server). This resolves an important TODO(relay) in the code. Signed-off-by: David Goulet <[email protected]>
* | Merge branch 'early-relay' into 'main'gabi-2502026-02-121-41/+104
|\ \ | |/ |/| | | | | | | | | proto: Pass *all* cells to handle_forward_cell() Closes #2339 See merge request tpo/core/arti!3674
| * proto: Remove unused function in relay FWD reactorGabriela Moldovan2026-02-121-7/+1
| |
| * proto: Move decode_relay_cell() out of ForwardHandlerGabriela Moldovan2026-02-121-27/+36
| | | | | | | | | | | | | | | | This doesn't need to be part of the `ForwardHandler` trait anymore, because the base reactor no longer calls it directly (instead implementations are supposed to handle it internally). No functional changes here, just code motion.
| * proto: Forbid EXTEND2 from RELAY cellsGabriela Moldovan2026-02-121-1/+9
| | | | | | | | Closes #2339
| * proto: Return a protocol error if we get too many RELAY_EARLYGabriela Moldovan2026-02-121-1/+20
| |
| * proto: Overhaul forward cell handlingGabriela Moldovan2026-02-121-8/+37
| | | | | | | | | | | | | | | | | | | | | | This pushes the RELAY/REALY_EARLY handling inside `handle_forward_cell()`, which now decodes the relay cells and * handles them internally, if they are unrecognized (`handle_unrecognized_cell()`), or * returns them back to the base reactor if they are recognized (RELAY and RELAY_EARLY cells are handled the same way by the base reactor)
| * proto: Give handle_forward_cell() a handle to the hopmgrGabriela Moldovan2026-02-121-1/+5
| | | | | | | | | | Soon this function will be in charge of decoding the cell too, so it will need a handle to the `HopMgr` (see `decode_relay_cell()`)
* | Merge branch 'channel-canonical' into 'main'David Goulet2026-02-124-29/+57
|\ \ | |/ |/| | | | | Implement channel canonicity See merge request tpo/core/arti!3668
| * proto: Enforce that channel method as unique SocketAddrDavid Goulet2026-02-122-22/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
| * proto: Channel finish() now handles canonicityDavid Goulet2026-02-124-20/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* | proto: Return internal error on TRUNCATEGabriela Moldovan2026-02-121-1/+1
|/ | | | | | | | 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).
* proto: Implement validate_backward_cell() for relaysGabriela Moldovan2026-02-111-3/+34
| | | | Closes #2345
* proto: Extend BWD handler with a backward cell handling functionGabriela Moldovan2026-02-111-1/+10
| | | | This will tell the base `BackwardReactor` how to handle the cell.
* proto: Relay responder channel allow to be non_exhaustiveDavid Goulet2026-02-091-1/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Publicly re-export MaybeVerifiableRelayResponderChannelDavid Goulet2026-02-092-0/+3
| | | | | This type is needed in the tor-chanmgr crate in order to decide to verify or not the underlying relay channel.
* relay: Add a TLS acceptor in the ChanBuilderDavid Goulet2026-02-091-2/+10
| | | | | | | | | | | | | | | 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]>
* proto: Say why it's okay not to have timeouts in a couple of placesGabriela Moldovan2026-02-091-0/+6
|
* proto: Remove the EXTEND2 timeout for nowGabriela Moldovan2026-02-091-26/+11
| | | | | See discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3648#note_3339863
* proto: Reject EXTEND2 cells even if we already have an extension in progressGabriela Moldovan2026-02-091-1/+12
|
* proto: Ensure DESTROY gets sent on circuit dropGabriela Moldovan2026-02-051-3/+9
| | | | | | | | | | 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. ```
* proto: Make handle_extend2() synchronousGabriela Moldovan2026-02-051-3/+2
| | | | | This doesn't need to be async, as it delegates the handling to a background task.
* proto: Implement EXTEND2 handlingGabriela Moldovan2026-02-051-17/+248
| | | | | | | | 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.
* proto: Reword an error message for clarityGabriela Moldovan2026-02-051-1/+1
| | | | Users reading the log won't necessarily know what a "forward channel" is.
* proto: Give handle_meta_msg() a handle to the runtimeGabriela Moldovan2026-02-051-1/+2
|
* proto: Add an implementation-dependent reactor event streamGabriela Moldovan2026-02-052-1/+23
| | | | | This will enable us to obtain implementation-dependent asynchronous events (such as the outcome of an extend handshake).
* proto: Make chan_provider an ArcGabriela Moldovan2026-02-052-3/+4
| | | | To match the `ChannelProvider::get_or_launch()` function signature.
* proto: Pass the unique id to Forward handlerGabriela Moldovan2026-02-052-1/+6
| | | | | | 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.
* proto: Move channel provider out of the generic reactorGabriela Moldovan2026-02-052-4/+17
| | | | | | 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.
* proto: Make inner part of OutboundChanSender pub(crate)Gabriela Moldovan2026-02-051-1/+1
| | | | We will need the ability to build one from within tor-proto.
* proto: Make ChannelProvider::get_or_launch() synchronousGabriela Moldovan2026-02-051-1/+1
| | | | This just removes an unnecessary `async`.
* proto: Add missing clock_skew() to unverified channelsDavid Goulet2026-02-042-2/+12
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Relay channel code cleanupDavid Goulet2026-02-041-323/+4
| | | | | | No need for these types, we've replaced them with more specific types. Signed-off-by: David Goulet <[email protected]>
* proto: Introduce new relay responder channel typesDavid Goulet2026-02-043-20/+211
| | | | | | | | | | Add the unverified, verified, non verifiable flavor types of a responder channel. This follow on the previous commit to use the type system for stronger guarantees. Signed-off-by: David Goulet <[email protected]>
* proto: Introduce new relay initiator channel typesDavid Goulet2026-02-043-4/+188
| | | | | | | | | | | | | | | | | | | This commit adds the Unverified and Verified flavor of a relay channel specific to an initiator. We decided to use the type system for safety and avoid patterns like: "if chan.is_initiator() {...} else {...}" This allows us also to not duplicate code between initiator and responder code. The downside is that we expose these types outside of tor-proto meaning the caller needs to feature gate the usage of these types with the "relay" flag. Small price to pay for strong guarantees with the type system. Signed-off-by: David Goulet <[email protected]>
* proto: Move the ChannelAuthenticationData::build() function into the object ↵David Goulet2026-02-041-0/+85
| | | | | | | | | itself Previous function "build_auth_data()" is still around but will be removed in the upcoming commits. Signed-off-by: David Goulet <[email protected]>
* proto: Remove unused async from relay reactorGabriela Moldovan2026-01-291-1/+1
| | | | Fixes a clippy warning
* proto: Rename chan senders and sinks for clarityGabriela Moldovan2026-01-291-1/+1
| | | | | | | | | | We settled on * `inbound_chan{tx, rx}`, for the inbound channel (the channel towards the guard, if we are a client, or towards the client if we are a relay) * `outbound_chan{tx, rx}`, for the outbound channel (the channel towards the exit, if we are a middle relay)
* proto: Replace relay reactor with new generic reactorGabriela Moldovan2026-01-293-1733/+192
|
* proto: Avoid locking in CircHopOutbound::ccontrol()Gabriela Moldovan2026-01-292-5/+9
| | | | | | | | This is just because the generic reactor will soon need a clone of the CC object, so I am preemptively making this function return a ref to the underlying `Arc` instead. Technically, it would've been fine to just kept this method and add a separate one returning `&Arc<Mutex<..>>`, but I'd prefer keeping the API small.
* proto: s/Forward/ForwardSender for clarityGabriela Moldovan2026-01-291-3/+3
| | | | | This renaming is needed because I will soon introduce a new `Forward` struct, with a completely different purpose.
* proto: Rip CC state out of CircHopInboundGabriela Moldovan2026-01-292-2/+4
| | | | | | Soon it won't need be needed here any more. I'm removing it, because having redundant handles to the CC state makes it difficult to see exactly where it's being used from.
* proto: Add exceptions for clippy::unused async in relay reactorGabriela Moldovan2026-01-271-0/+3
| | | | This code is still WIP, so I propose we ignore the lint for now.
* proto: Improve some comments in relay moduleDavid Goulet2026-01-221-0/+6
| | | | Signed-off-by: David Goulet <[email protected]>
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 04:47:55 +0000