aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/channel
Commit message (Collapse)AuthorAgeFilesLines
...
* proto: Add RelayInitiatorHandshakeDavid Goulet2025-10-231-1/+7
| | | | | | | 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-14/+14
| | | | | | | | | | 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-132-4/+6
| | | | | 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
|
* proto: Make DynTimeProvider explicit in channel padder types.Nick Mathewson2025-10-021-2/+6
|
* proto: Trigger maybenot events for channel-level padding.Nick Mathewson2025-10-021-7/+35
|
* proto: Add maybenot padding objects to the channel reactorNick Mathewson2025-10-011-1/+16
|
* opentelemetry: Add some instrument macros.Wesley Aptekar-Cassels2025-09-241-1/+4
| | | | | I've added these in places that are useful for the debugging that I've been doing.
* Merge branch 'expire-halfstream-cbt' into 'main'gabi-2502025-09-241-3/+9
|\ | | | | | | | | | | | | 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-2/+8
| |
| * circmgr: Pass the timeout estimator to circuit constructor.Gabriela Moldovan2025-09-161-3/+3
| | | | | | | | | | This enables us to read the CBT estimates from the circuit reactor (we need these to compute the half-stream timeouts for #264).
* | proto: resolve/edit trivial "TODO circpad" instances.Nick Mathewson2025-09-171-2/+6
| |
* | proto: for padding, count cells on each channel queues.Nick Mathewson2025-09-161-3/+1
|/ | | | We'll use this to implement `replace` for padding to the first hop.
* Merge branch 'maybenot-triggers' into 'main'Nick Mathewson2025-09-032-100/+204
|\ | | | | | | | | Circuit padding: note when cells are sent and received See merge request tpo/core/arti!3222
| * Whoops; let chains _still_ aren't stable in 1.85.Nick Mathewson2025-09-031-2/+1
| |
| * padding cleanup: use QueuedCellPaddingInfo one more place.Nick Mathewson2025-09-031-5/+3
| |
| * padding: Report when outbound cells are flushed.Nick Mathewson2025-09-022-3/+22
| | | | | | | | | | | | (This is what required us to stick a padding controller handle in each CircEnt, and what required us to accompany each queued cell with a QueuedPaddingCellInfo. Ouch!)
| * padding: Give CircEnt in a Channel a handle for the PaddingController.Nick Mathewson2025-09-022-88/+130
| | | | | | | | | | This requires some annoying plumbing to make sure that the right types wind up in the right places.
| * proto: Turn CircEnt variants into struct-like format.Nick Mathewson2025-09-022-29/+72
| | | | | | | | (I'm about to add more fields.)
| * padding: track which hop each queued cell is for.Nick Mathewson2025-09-021-5/+8
| | | | | | | | | | | | | | | | 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: Move is_authenticating() into the base initiator handshake traitDavid Goulet2025-09-021-7/+10
| | | | | | | | | | | | | | | | Initiator always know if they will authenticate or not. Responder is different as a relay doesn't know until the end of the handshake if it is responding to a relay or a client. Signed-off-by: David Goulet <[email protected]>
* | proto: Various channel handshake fixesDavid Goulet2025-09-021-21/+38
| | | | | | | | | | | | | | | | | | | | These are following the review of MR 3182. They are put in a single commit because the git absorb has a large amount of conflicts on rebase and this commit allows the reviewers to see what happened. The base branch was rebased on main due to the need for 3184. Signed-off-by: David Goulet <[email protected]>
* | proto: Fix unit tests after changesDavid Goulet2025-09-021-5/+5
| | | | | | | | Signed-off-by: David Goulet <[email protected]>
* | proto: Add a helper to calculate the handshake clock skewDavid Goulet2025-09-021-12/+33
| | | | | | | | | | | | In the spirit of avoidin code duplication. Signed-off-by: David Goulet <[email protected]>
* | proto: Add a channel initiator handshake base traitDavid Goulet2025-09-021-76/+118
| | | | | | | | | | | | | | | | | | All initiator handshake will implement this in order to get access to the helper function to receive the relay responder cells. Relay will implement this in future commits. Signed-off-by: David Goulet <[email protected]>
* | proto: Introduce a ChannelBaseHandshake traitDavid Goulet2025-09-021-37/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Client and relay handhsake share a lot of code because they both send/recv the same cells, just handles them differently for verification. This is the base trait for all handshake implementing basic getters and VERSIONS cell handling. This will allow the RelayInitiatorHandshake and RelayResponderHandshake to use this common code. See, traits are fun. Win-win-win. Signed-off-by: David Goulet <[email protected]>
* | proto: Put in a ChannelFrame<T> into the client handshakeDavid Goulet2025-09-021-10/+9
|/ | | | | | | | | | | | The ClientInitiatorHandshake holds a "tls" sink but the very first thing we do is transform it to a ChannelFrame<T>. Instead, just store the frame to the object directly so we can then use a channel frame uniformily accross its lifetime. This will be useful for the future refactoring paving the way for relay channel authentication. Signed-off-by: David Goulet <[email protected]>
* proto: Add a circuit module shared between client and relay impls.Gabriela Moldovan2025-08-282-3/+3
| | | | | | | 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: Only allow VERSIONS cell for the new handshake stateDavid Goulet2025-08-272-51/+20
| | | | | | | | | Due to this, it is not possible to get a VPADDING before because it requires a link protocol version to decideon the encoding: https://gitlab.torproject.org/tpo/core/torspec/-/issues/366 Signed-off-by: David Goulet <[email protected]>
* proto: Remove the AUTHORIZE as a parsable cellDavid Goulet2025-08-212-19/+2
| | | | | | | | | | | | | 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: Add a channel handler comment and a fixDavid Goulet2025-08-211-3/+8
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Return AUTHORIZE, VPADDING and VERSIONS at handshakeDavid Goulet2025-08-212-24/+65
| | | | | | | | When starting a handshake, we were only expecting a VERSIONS which is not what the protocol say. An AUTHORIZE and VPADDING can arrive before a VERSIONS. Signed-off-by: David Goulet <[email protected]>
* proto: Allow padding in all channel message setsDavid Goulet2025-08-211-3/+13
| | | | | | | | | | | | | | First of all, VPADDING has been added in link protocol version 3 so it was missing from v4. Second, after closely looking at C-tor and the spec, it appears that we allow VPADDING at any point on a channel which should simply be silently dropped. Any number in any order. Third, couple sets were missing the PADDING cell which is only allowed on an open channel. Signed-off-by: David Goulet <[email protected]>
* tor-proto: simplify some match statementsSteven Engler2025-08-201-46/+26
|
* proto: Change (crate) to (super) for all objects in msg.rsDavid Goulet2025-08-201-25/+25
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Cleanup allow(unused)David Goulet2025-08-202-4/+0
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Unit tests for channel handlerDavid Goulet2025-08-201-1/+107
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Rename OutboundClientHandshakeDavid Goulet2025-08-201-6/+6
| | | | | | | | | 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-203-178/+90
| | | | | | | | | | | | | | | | | 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 channel cell handlerDavid Goulet2025-08-201-0/+561
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 message filtering to restricted message setsDavid Goulet2025-08-201-2/+361
| | | | | | | | | | | | | | | | | This adds the code in msg.rs to be able to filter an inbound or outbound message on a channel. Each link protocol version implement a "is_allowed()" which is quite verbose and tests each possibilities for human readability. Then, we have several small struct/enum that are used to describe how a message is filtered. It is still unused at this commit. Part of #1597 Signed-off-by: David Goulet <[email protected]>
* proto: Add restricted channel message setsDavid Goulet2025-08-201-0/+207
| | | | | | | | | | | | | | | 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-202-2/+12
| | | | | | | | | | | | | | | | 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]>
* tor-proto: report tunnel/channel id as a fieldSteven Engler2025-08-181-2/+2
| | | | This restores the pre-374889d34aa0 behaviour.
* proto: Rename the `tunnel` module to `client` (fmt).Gabriela Moldovan2025-08-181-1/+1
|
* proto: Rename the `tunnel` module to `client`.Gabriela Moldovan2025-08-183-10/+10
| | | | | | The implementation from `tunnel` is client-specific, so we are renaming the module accordingly. The more generic parts will be pulled into a separate module in a future commit.
* tor-proto: use error report in tunnel/channel reactorSteven Engler2025-08-071-1/+10
|
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 03:27:50 +0000