summaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/channel.rs
Commit message (Collapse)AuthorAgeFilesLines
* proto: Move TimeoutEstimator to utilGabriela Moldovan2026-01-291-1/+2
| | | | | This will be used in the stream reactor too (and the stream reactor will eventually replace the corresponding client impl).
* proto: Improve some comments in relay moduleDavid Goulet2026-01-221-1/+2
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Remove async for VerifiableChannel::check()David Goulet2026-01-221-2/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Move cell sending out of check() and into finish()David Goulet2026-01-221-5/+0
| | | | | | | | | | | | | This is so check() only authenticate a channel. The finish() function now only sends back the missing cells and build the final Channel. To pull this off, the AUTHENTICATE cell and our IP addresses need to be copied into the VerifiedRelayChannel. This allows us to remove complexity into the check() function as well and future commit will remove the async. Signed-off-by: David Goulet <[email protected]>
* proto: Authenticate a relay channelDavid Goulet2026-01-221-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit is a bit loaded but it is coherent. First, we set Eq and PartialEq to the channel message Authenticate so we can compare it with the one we expected. Second, the AuthenticationCell enum is introduced to store either an AUTH_CHALLENGE or an AUTHENTICATE since one side of the handshake can only have one. This allows us to store one or the other in UnverifiedRelayChannel. Depending on what we have, the authentication process is different as it dictates which side we are on (initiator vs responder). Keep in mind that the handshake code enforces receiving a AUTH_CHALLENGE along side CERTS. And same goes for AUTHENTICATE which means that if we have an AUTH_CHALLENGE in the UnverifiedRelayChannel, it is certain that the other side wants to authenticate and we are the initiator. Finally, the sending of CERTS and AUTHENTICATE by the initiator is now in UnverifiedRelayChannel::check() done right after verifying the channel CERTS and holding a "VerifiedChannel" object. This means that the last piece, sending the `NETINFO` by the initiator will be done in the check() but in a future commit. This leaves the VerifiableChannel::finish() to send nothing and only finalize the channel with the NETINFO (canonicity). Signed-off-by: David Goulet <[email protected]>
* proto: Make VerifiableChannel::check() asyncDavid Goulet2026-01-221-1/+2
| | | | | | | | | Relay initiator needs to send CERTS and AUTHENTICATE in that function after verifiying the channel. And thus require to be async. Signed-off-by: David Goulet <[email protected]>
* proto: Make CERTS cell optionnable for UnverifiedChannelDavid Goulet2026-01-221-0/+7
| | | | | | | | | | | | | | | This requires to make a series of cert and digest also optionnable in the VerifiedChannel. This change is needed because as a relay responder, you might get the CERTS or not depending on if the other side wants to authenticate. Client and bridges do not authenticate and thus it is expected to not have a CERTS cell. This leads to the UnverifiedChannel::check() function to return early with a VerifiedChannel without any identity attached to it. Signed-off-by: David Goulet <[email protected]>
* proto: Fix comments documentationDavid Goulet2026-01-131-1/+1
|
* proto: Seal the VerifiableChannel and FinalizableChannel traitsDavid Goulet2026-01-131-2/+10
| | | | | | They are public but avoid anyone outside implementing them. Signed-off-by: David Goulet <[email protected]>
* proto: Improve channel trait commentsDavid Goulet2026-01-131-0/+7
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Add link_protocol() to VerifiableChannel traitDavid Goulet2026-01-131-0/+4
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Add traits for public channel viewsDavid Goulet2026-01-131-0/+53
| | | | | | | | | | | | | | Add traits that will be returned outside tor-proto allowing us to not expose client and relay specific channels. The goal is for the tor-chanmgr to get those objects implementing those traits and can build and run the reactor without knowing the specific underlying type. This allows us to have less code duplication and less client/relay distinction in the chanmgr. Signed-off-by: David Goulet <[email protected]>
* proto: Remove unused restricted channel msg setDavid Goulet2025-12-101-26/+0
| | | | Signed-off-by: David Goulet <[email protected]>
* opentelemetry: Instrument a bunch of functions.Wesley Aptekar-Cassels2025-11-241-1/+8
| | | | | These are all aimed at figuring out in more detail what's going on in #2079 and related issues.
* proto: Add a TODO relay for ChannelBuilderDavid Goulet2025-11-191-0/+2
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Make cargo doc happyDavid Goulet2025-11-191-2/+2
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Add client specific handshake channel structsDavid Goulet2025-11-191-1/+1
| | | | | | | | | | | | | | This adds the UnverifiedClientChannel and VerifiedClientChannel mirroring the relay API for channels. It plainly uses the generic object underneath as for now those objects are client only. Followup commits will make things more client specific. No behavior change. Signed-off-by: David Goulet <[email protected]>
* proto: Move client handshake into client channel moduleDavid Goulet2025-11-191-2/+9
| | | | | | | | | | | | | This only moves code from src/channel to src/client/channel. It introduces a ClientChanBuilder that is used to launch client specific channel by the public ChanBuilder. The followup commits will add a VerifiedClientChannel and UnverifiedClientChannel in order to again decouple client and relay code from the generic objects. Signed-off-by: David Goulet <[email protected]>
* proto: Add VerifiedRelayChannel implementationDavid Goulet2025-11-191-1/+2
| | | | | | | | Add the finish() function that for now simply calls the generic finish(). There is a bunch of TODO in the code in this commit explaining why we haven't made the implementation relay specific just yet. Signed-off-by: David Goulet <[email protected]>
* proto: Add UnverifiedRelayChannel implementationDavid Goulet2025-11-191-7/+0
| | | | | | | | | | | | | | This commits takes out the relay specific code out of UnverifiedChannel and puts it in UnverifiedRelayChannel. In order to pull this off, we added some fiels to the VerifiedChannel struct so the relay code get back generated data from the UnverifiedChannel::check() in order to do its validation work and yield a VerifiedRelayChannel. This also lead to a cleanup of expect() and ChannelType::is_initiator(). Signed-off-by: David Goulet <[email protected]>
* tor-proto: Reduce `high_water_mark` of ChannelFramenield2025-11-061-1/+3
|
* proto: Feature flag some relay specific codeDavid Goulet2025-10-231-0/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Compute authenticate data after validating certificatesDavid Goulet2025-10-231-1/+0
| | | | | | | | | | | | | | This is only done if we kept the AUTH_CHALLENGE cell and we have relay identities. In other words, this is only when the UnverifiedChannel was created from a RelayInitiatorHandshake. Note: The check_internal() function is too large and should be refactored in smaller pieces. Note: It is also likely that we need to split UnverifiedChannel and VerifiedChannel as it is getting client or relay members. Not great. Signed-off-by: David Goulet <[email protected]>
* proto: Add RelayInitiatorHandshakeDavid Goulet2025-10-231-0/+1
| | | | | | | This implements the relay initiator side of the handshake up to the creation of an unverified channel. Signed-off-by: David Goulet <[email protected]>
* proto: Change visibility for some channel objectsDavid Goulet2025-10-231-5/+5
| | | | | | | | | | Upcoming code for relay channels are put in the src/relay module and thus we need visibility into some channel generic things. Turns out also we don't need to re-export publicly UnverifiedChannel and VerifiedChannel. Signed-off-by: David Goulet <[email protected]>
* proto: Move celltypes out of clientGabriela Moldovan2025-10-131-1/+1
| | | | | 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/+30
|
* proto: start implementing logic for padding actions.Nick Mathewson2025-10-021-0/+1
|
* Add a blocker to channel outbound sink.Nick Mathewson2025-10-021-0/+7
|
* proto: Generate per-sender NormalSent events from circuits.Nick Mathewson2025-10-011-1/+7
|
* proto: Propagate PaddingCtrl into ChannelSender.Nick Mathewson2025-10-011-43/+68
| | | | We'll need it to tell the channel padder when padding is queued.
* proto: Add maybenot padding objects to the channel reactorNick Mathewson2025-10-011-0/+10
|
* Merge branch 'expire-halfstream-cbt' into 'main'gabi-2502025-09-241-1/+3
|\ | | | | | | | | | | | | proto: Remove half-streams when they expire. Closes #264 See merge request tpo/core/arti!3267
| * circmgr: Pass the timeout estimator to circuit constructor (fmt).Gabriela Moldovan2025-09-161-1/+1
| |
| * circmgr: Pass the timeout estimator to circuit constructor.Gabriela Moldovan2025-09-161-3/+2
| | | | | | | | | | This enables us to read the CBT estimates from the circuit reactor (we need these to compute the half-stream timeouts for #264).
| * proto: Use the CBT to compute half-stream timeouts.Gabriela Moldovan2025-09-161-0/+3
| |
* | proto::channel: Remove some statements about limitations.Nick Mathewson2025-09-171-6/+1
| | | | | | | | | | These have all become false, except for the one about being client-only, which is recapitulated at the crate level.
* | proto: Consider the channel queue with "Replace" padding to hop 1.Nick Mathewson2025-09-161-1/+0
| | | | | | | | | | | | | | | | | | When we want to send Replace padding (that is, padding that should only be sent if nothing else is queued) to hop 1, we can allow it to be replaced by cells from _any_ circuit being sent over the same channel. (Nobody but hop 1 can tell the difference.) Closes #2169
* | proto: for padding, count cells on each channel queues.Nick Mathewson2025-09-161-10/+60
|/ | | | We'll use this to implement `replace` for padding to the first hop.
* padding: Give CircEnt in a Channel a handle for the PaddingController.Nick Mathewson2025-09-021-2/+6
| | | | | This requires some annoying plumbing to make sure that the right types wind up in the right places.
* padding: track which hop each queued cell is for.Nick Mathewson2025-09-021-10/+14
| | | | | | | | We'll need this so that we can tell the right padding machine(s) which of them just had a queue flush. This is not yet 100% done; the unfinished parts are marked with XXXXs.
* proto: Add a circuit module shared between client and relay impls.Gabriela Moldovan2025-08-281-1/+1
| | | | | | | This is just code motion (I suggest reviewing with `--color-moved`). This also moves the implementation-agnostic parts from `tor_proto::client::circuit` to a new `tor_proto::circuit` module.
* proto: Remove the AUTHORIZE as a parsable cellDavid Goulet2025-08-211-5/+6
| | | | | | | | | | | | | The AUTHORIZE cell command is simply reserved but not defined. The tor specification, at this point in time, is allowing such cell before the handshake starts but it is very unclear on what ordering is allowed nor how many can are allowed. C-tor silents drop them like VPADDING and so clearly unused. Instead of dealing with it, simply remove its support but keeping its reserved number. Signed-off-by: David Goulet <[email protected]>
* proto: Rename OutboundClientHandshakeDavid Goulet2025-08-201-5/+5
| | | | | | | | | Use the specification terminology which is also the same for ChannelType. Part of #1597 Signed-off-by: David Goulet <[email protected]>
* proto: Make the OutboundClientHandshake use new cell handlerDavid Goulet2025-08-201-15/+3
| | | | | | | | | | | | | | | | | Use the ChannelFrame<> for the entirety of the outbound client handshake that is the ClientInitiator channel type. With this change, the codec.rs code is not needed anymore along its CodecError as well which has been normalized onto the crate::Error instead in order to simplify error handling and avoid duplication of error types. Unit tests have been modified to reflect this change of what can be done with a channel frame. Also renamed to focus on client behavior. Part of #1597 Signed-off-by: David Goulet <[email protected]>
* proto: Add helper functions/type for cell handlingDavid Goulet2025-08-201-0/+20
| | | | | | | | | This type and functions will be used in the handshake process in future commits. Part of #1597 Signed-off-by: David Goulet <[email protected]>
* proto: Add channel cell handlerDavid Goulet2025-08-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The handler.rs file contains a generic "ChannelCellHandler" which is split into three different handler depending of the channel state (new, handshaking or open). These handlers implement Encoder/Decoder so we can give a ChannelCellHandler to a asynchronous_codec::Framed along a TLS stream. That cell handler is also in charge of tracking the CLOG/SLOG (see tor-spec), running digest of cells seen, which is used to authenticate a channel for the Relay <-> Relay case. This ChannelCellHandler auto transitions as the setters function are used. The handshake code will use this to advance the handler. Each handler uses a MessageFilter from msg.rs in order to allow or not to return the message. A keen eye will notice that we can avoid encoding a message if we don't need but we will decode all possible messages and only then allow it or not. The channel cell handler is not used at this commit. Part of #1597 Signed-off-by: David Goulet <[email protected]>
* proto: Add restricted channel message setsDavid Goulet2025-08-201-3/+4
| | | | | | | | | | | | | | | Add the msg.rs file containing all the allowed message sets based on the channel type and direction. They are also namespaced by link protocol version. Unused at this commit. They will be used by the channel reactor along the channel type and link protocol version in order to know if the message is allowed or not. See is_allowed() helper function in this commit. Part of #1597 Signed-off-by: David Goulet <[email protected]>
* proto: Add ChannelType enumDavid Goulet2025-08-201-8/+53
| | | | | | | | | | | | | | | | The ChannelType indicates the type of channel in order to dictate which message is allowed on it. The value use the Initiator and Responder terminology from tor-spec documents. At this commit, we only have client channel meaning the "ClientInitiator" type. In future commits, the channel type will be used by the channel reactor to restrict which message is allowed or not. Part of #1597 Signed-off-by: David Goulet <[email protected]>
* chan: Rename channel launch to launch_clientDavid Goulet2025-08-201-2/+2
| | | | Signed-off-by: David Goulet <[email protected]>
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 11:12:14 +0000