aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/channel/reactor.rs
Commit message (Collapse)AuthorAgeFilesLines
* proto: Avoid sending DESTROY if we have received DESTROYGabriela Moldovan8 days1-0/+7
| | | | | | | | | | | | | | | This change prevents the channel reactor from sending DESTROY cells on already-closed (or non-existent) circuits. Upon receiving a DESTROY cell, the channel reactor removes the corresponding circuit entry, if any, from its circmap. It then passes the DESTROY to the circuit reactor for handling. The circuit reactor handles it by shutting down, and calling `Channel::close_circuit()` on drop. Previously, this would unconditionally send a DESTROY cell, which caused #2648 and #2646. This affects both clients and relays, because both circuit reactors call `Channel::close_circuit()` on drop. Closes #2648, #2646
* Merge branch 'unk-circid' into 'main'gabi-25013 days1-32/+40
|\ | | | | | | | | | | | | proto: Silently drop DESTROY/RELAY/CREATED cells on unknown circuits Closes #2655 See merge request tpo/core/arti!4301
| * proto: Explicitly drop the cells with unrecognized CircIdsGabriela Moldovan2026-08-121-0/+20
| | | | | | | | And say why it's okay to do so.
| * proto: Update tests now that unrecognized CREATED are droppedGabriela Moldovan2026-08-111-2/+2
| | | | | | | | | | These are no longer causing the channel reactor to shut down, so we need to update this test accordingly.
| * proto: Update tests now that we tolerate unrecognized CircIdsGabriela Moldovan2026-08-111-24/+8
| |
| * proto: s/channel/circuit in test commentGabriela Moldovan2026-08-111-1/+1
| |
| * proto: Ignore CREATED* with unrecognized CircIdsGabriela Moldovan2026-08-111-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we're a relay, we need to tolerate CREATED* with unrecognized CircIds: for example, if we time out[^1] while trying to extend the circuit by another hop, we will send a DESTROY to the extending hop, which can race with the CREATED* response. In other words, a CREATED* cell arriving on a closed circuit shouldn't be treated as a protocol violation. There are, however, a few cases where a CREATED* with an unknown CircId *is* a protocol violation (and probably *should* cause us to close down the channel): * if the CREATED* is moving in the forward direction (towards the exit), or * if we have not previously sent a CREATE* with that particular CircId As before, distinguishing these from the "closed circuit" case above would involve some tricky logic, and the benefits are unclear, while the downsides of closing a channel when we shouldn't have are significant. It seems better to just drop these cells for now. Closes #2655 [^1]: at the time of writing, we don't have timeouts for the circuit extension logic, so what I've described here cannot actually happen today. However, we *do* have a TODO for it, so the time outs I've described here will be implemented at some point
| * proto: Silently drop DESTROY/RELAY cells on unknown circuits (fmt)Gabriela Moldovan2026-08-111-5/+3
| |
| * proto: Silently drop DESTROY/RELAY cells on unknown circuitsGabriela Moldovan2026-08-111-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An unrecognized circuit ID is not always a protocol violation, so we shouldn't close down the channel if it happens. This change makes the channel reactor drop DESTROY and RELAY cells with unknown CircIds without closing down the channel. It affects both clients and relays. Instead of dropping these unconditionally, we could have implemented some more sophisticated checks to distinguish the bogus CircIds from the CircIds of closed circuits, but it's unclear if it's worth the added complexity (see discussion in #2655). This partly addresses #2646 (an unrecognized circuit ID shouldn't cause us to close down the channel if we're a relay). This commit partially undoes the changes from 4f567e4a9432b340c2799e600c8ceb3724ad3082, which was originally intended to mitigate flooding attacks. Part of #2655
* | tor-proto: make `CreateRequestHandler` methods asyncSteven Engler2026-08-121-10/+13
|/
* proto: Rename "hs" to "hc"Gabriela Moldovan2026-08-041-1/+1
| | | | | I think this might have been c&p from the half-stream code ("hs" = "half-stream"). "hc" ("half-circuit") seems like a better name.
* align DestroyReason with torspec!490ramdoys2026-07-281-1/+1
|
* proto: Update the tests to use the new CircuitRx{Receiver,Sender}sGabriela Moldovan2026-06-081-1/+1
|
* proto: Apply deferred rustfmtGabriela Moldovan2026-04-231-5/+2
|
* proto: Build the PeerInfo from the dummy target in the testsGabriela Moldovan2026-04-231-5/+14
| | | | | The new relay circuit reactor test expect the `PeerInfo` to be populated with the identity keys of the peer, and won't work without this change.
* tor-proto: give our rsa ident to the channel reactorSteven Engler2026-04-161-1/+5
| | | | This will be needed for ntor handshakes.
* tor-proto: small comment improvementSteven Engler2026-04-091-1/+2
|
* tor-proto: replace a tuple with a dedicated structSteven Engler2026-04-091-13/+23
|
* tor-proto: give our ed ident to the channel reactorSteven Engler2026-04-091-2/+7
| | | | This will be needed for ntor handshakes.
* tor-proto: take `CreateRequest` message by referenceSteven Engler2026-04-081-1/+1
| | | | | Clippy has started warning about this since we moved the CREATE_FAST handling to a helper, so this resolves that.
* Revert "tor-proto: change `CreateResponse` to `restricted_msg!`"Steven Engler2026-04-081-13/+2
| | | | This reverts commit 9c38daf2d3548feca2ff555f5bd52165add0d20c.
* tor-{proto,chanmgr}: change how channels accept a CREATE* handlerSteven Engler2026-04-081-23/+2
| | | | | | | | | | | Instead of giving the `CreateRequestHandler` to the channel after it's constructed, we integrate it into the handshake so that we can give it to the channel constructor. The `ChannelType` is no longer part of the `Channel`. Some of the tests could be cleaned up slightly now that the channel doesn't need the `ChannelType`, but I don't want to conflict with !3853.
* tor-proto: remove TODO about `UniqId` overflowSteven Engler2026-04-081-2/+2
|
* tor-proto: handle incoming RELAY_EARLY messagesSteven Engler2026-04-081-2/+10
|
* tor-proto: add `Channel::set_create_request_handler()`Steven Engler2026-04-081-0/+21
| | | | | | We can't pass the request handler during the `Channel` constructor since it would require conditionally compiled function arguments, which aren't nice.
* tor-proto: add `CreateRequestHandler`Steven Engler2026-04-081-0/+99
| | | | for handling CREATE* messages on channels.
* tor-proto: change `CreateResponse` to `restricted_msg!`Steven Engler2026-04-081-2/+13
| | | | | This better fits with existing code that uses `restricted_msg!` and is a bit more flexible.
* tor-proto: change channel to use `Runtime`Steven Engler2026-04-081-6/+6
| | | | | When used for relay channels, the channel reactor will soon need to spawn relay circuit reactors.
* tor-proto: support relay circs in channel's `CircMap`Steven Engler2026-04-081-11/+30
|
* tor-proto: rename `CircEnt::Open` to `CircEnt::OpenOrigin`Steven Engler2026-04-081-7/+7
| | | | And rename `CircMap::add_ent()` to `add_origin_ent()`.
* safelog: Rename MaybeSensitive::hidden/visible()David Goulet2026-03-031-1/+1
| | | | | | Rename them to respectively sensitive() and not_sensitive(). Signed-off-by: David Goulet <[email protected]>
* proto: Setup the channel PeerInfo in the specialized finish()David Goulet2026-03-031-1/+1
| | | | | | | | | | | Every specific types know if the peer is sensitive or not so now the finish() of each of these channel types builds the right PeerInfo with MaybeSensitive. This is passed on the Channel so from that point on, the Channel will never leak peer data in the logs. Signed-off-by: David Goulet <[email protected]>
* proto: Remove Default of PeerInfo/Addr and use const insteadDavid Goulet2026-02-191-1/+2
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Put a PeerInfo in ChannelDavid Goulet2026-02-191-0/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Channel finish() now handles canonicityDavid Goulet2026-02-121-1/+2
| | | | | | | | | | | | | | 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]>
* Merge branch 'unused-async-lint' into 'main'gabi-2502026-01-281-2/+3
|\ | | | | | | | | | | | | maint/add_warning: Deny clippy::unused_async Closes #2328 See merge request tpo/core/arti!3613
| * proto: Add an exception for clippy::unused_asyncGabriela Moldovan2026-01-271-0/+1
| |
| * proto: Remove unnecessary async in channel reactorGabriela Moldovan2026-01-271-2/+2
| | | | | | | | | | This resolves a warning triggered by the newly-introduced `#[deny(clippy::unused_async)]`.
* | clippy: Fix missing doc for non-Linux buildsClara Engler2026-01-271-0/+1
|/
* proto: Move unit tests and minor fixDavid Goulet2025-12-101-3/+3
| | | | | | Move the client specific unit tests into the client module. Signed-off-by: David Goulet <[email protected]>
* proto: Client circuit reactor now handles AnyChanMsgDavid Goulet2025-12-101-4/+4
| | | | | | | | | | | | | | | This commit removes the CircuitRx* based solely on the client circuit message and moves it into the top level of the crate so all reactors can use them. The client reactor then upon receiving the message, it converts the AnyChanMsg into a ClientCircChanMsg. On error, this leads to a shutdown of the entire reactor due to a fatal error. In order to pull this off, we added a CircuitAction::Shutdown that is handled as a priority. Signed-off-by: David Goulet <[email protected]>
* proto: Move ClientCircChanMsg into client moduleDavid Goulet2025-12-101-2/+1
| | | | | | | | Next commit will also move the Relay specific set into the relay module. These two sets are becoming specific to the reactor as the circuit reactor communication channel will use AnyChanMsg instead. Signed-off-by: David Goulet <[email protected]>
* opentelemetry: Instrument a bunch of functions.Wesley Aptekar-Cassels2025-11-241-1/+5
| | | | | These are all aimed at figuring out in more detail what's going on in #2079 and related issues.
* all: run cargo fmtSteven Engler2025-11-041-1/+1
|
* all: replace all uses of `futures::task::SpawnExt` with `tor_rtcompat::SpawnExt`Steven Engler2025-11-041-1/+1
|
* proto: Move celltypes out of clientGabriela Moldovan2025-10-131-3/+4
| | | | | Some of these are relay-specific, so it makes more sense to pull this into a top-level module.
* proto: experimental API to install a per-channel padder.Nick Mathewson2025-10-021-0/+14
|
* proto: Implement channel padding with maybenot padders.Nick Mathewson2025-10-021-8/+95
| | | | With this commit we now actually generate padding when we're told to.
* proto: start implementing logic for padding actions.Nick Mathewson2025-10-021-2/+41
|
* Add a blocker to channel outbound sink.Nick Mathewson2025-10-021-1/+12
|
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 23:14:06 +0000