aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/relay
Commit message (Collapse)AuthorAgeFilesLines
...
* proto: Enforce condition with type systemDavid Goulet2026-01-221-5/+6
| | | | | | | | This commits returns either Some(AUTH_CELL, CERTS) or None. We future proof ourselves against one Some and other None even if an error check is done before. Signed-off-by: David Goulet <[email protected]>
* proto: Fix the link auth handling from the AUTH_CHALLENGEDavid Goulet2026-01-221-2/+3
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Use the channel codec channel typeDavid Goulet2026-01-222-5/+1
| | | | | | | | | | | | | | | | | Remove the channel type from Unverified and Verified channels and instead use the channel type in the underlying channel codec. The codec requires such type in order to restrict messages sets. Instead of duplicating it, this commit simply makes it that there is now only a single channel type attached to a channel structure. The resulting `struct Channel` in the end gets it copied from the channel codec as the framed_tls gets split and given to the `Reactor`. Down the line, we need a channel type attached to the `Channel` in order to know if it is a client or not and authenticated or not. Signed-off-by: David Goulet <[email protected]>
* proto: Improve comments on build_auth_data() about clog/slogDavid Goulet2026-01-221-0/+4
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Remove Option<> around peer_ip for build_netinfo_cell()David Goulet2026-01-222-4/+5
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Put rsa_id and rsa_cert_digest togetherDavid Goulet2026-01-221-3/+6
| | | | | | Avoid having one None and the other Some which would be a bug. Signed-off-by: David Goulet <[email protected]>
* proto: Avoid magic hardcoded value for LINK_AUTHDavid Goulet2026-01-222-3/+3
| | | | | | | Instead, use the static AUTHTYPE_ED25519_SHA256_RFC5705 value which is for now the only version we support. Signed-off-by: David Goulet <[email protected]>
* proto: Enforce CERTS and AUTHENTICATE are always expected togetherDavid Goulet2026-01-221-0/+6
| | | | | | | A Responder receiving cells from the Initiator, if it gets a CERTS, an AUTHENTICATE must also be present (and vice-versa). 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-32/+42
| | | | | | | | | | | | | 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: Implement FinalizableChannel for an unverified relay channelDavid Goulet2026-01-221-33/+62
| | | | | | | | | | | | | | | Reason for this is so we can use the type system to enforce that a client/bridge<-> relay channel can never become verified and thus in the code path of authentication. In other words, when check() is called, without an authentication cell, we can't authenticate or even verify the identities so we immediately return "self" which in this case is the UnverifiedRelayChannel. That channel can be finish()-ed to yield a Channel that can never be considered authenticated. Signed-off-by: David Goulet <[email protected]>
* proto: Send relay channel NETINFO in check()David Goulet2026-01-222-19/+25
| | | | | | | | | | Once channel is verified and authenticate if need be, send the NETINFO. We require our advertised IP addresses for this so pass them to launch() as well to the UnverifiedRelayChannel. A cargo fmt change slipped in here, sorry about that. Signed-off-by: David Goulet <[email protected]>
* proto: Authenticate a relay channelDavid Goulet2026-01-222-32/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Add CertifiedConn to relay handshakeDavid Goulet2026-01-222-17/+17
| | | | | | | We need this trait for the underlying TLS stream in order to access data such as the certificates or keying material. Signed-off-by: David Goulet <[email protected]>
* proto: Add relay link signing kp to RelayIdentitiesDavid Goulet2026-01-221-0/+5
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Add UnverifiedRelayChannel::build_auth_data()David Goulet2026-01-221-37/+101
| | | | | | | | | | | | | | | | | | Reason for this is because both initiator and responder build the authentication data in order to send it (initiator) and validate it (responder). The build_auth_data() function takes a VerifiedChannel as an argument in order to access the CLOG/SLOG data and authentication data MUST always be handled after a channel is verified as in its CERTS has been checked. Take the opportunity also to add the NETINFO and relay identities data into the verified channel which will be needed to finalize the channel. The check() function is now missing the actual validation of the AUTHENTICATE for a responder which will come in the next commit(s). Signed-off-by: David Goulet <[email protected]>
* proto: Implement RelayResponderHandshakeDavid Goulet2026-01-222-2/+264
| | | | | | | | | | | | | This commit introduces the RelayResponderHandshake object used when accepting an inbound connection to open a channel. There are still TODOs pepperred in the code but the base is implemented. The Unverified and Verified channel need to be adjusted for this new handshake. This will come in the next commits. Signed-off-by: David Goulet <[email protected]>
* proto: Add helper to build NETINFO cellDavid Goulet2026-01-221-13/+25
| | | | | | | Again, as the CERTS helper, this is used by both initiator and responder handshake. Signed-off-by: David Goulet <[email protected]>
* proto: Add a helper function to build CERTS cellDavid Goulet2026-01-221-1/+47
| | | | | | Both initiator and responder send CERTS cell hence this helper. Signed-off-by: David Goulet <[email protected]>
* proto: Make CERTS cell optionnable for UnverifiedChannelDavid Goulet2026-01-222-4/+11
| | | | | | | | | | | | | | | 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: Move relay channel related structs outside of handshake.rsDavid Goulet2026-01-222-269/+272
| | | | | | Code movement only. Signed-off-by: David Goulet <[email protected]>
* Merge branch 'ticket1599_02' into 'main'David Goulet2026-01-133-47/+54
|\ | | | | | | | | chanmgr: Ability for the ChanMgr to be channel type specific and launch relay channels See merge request tpo/core/arti!3563
| * proto: Fix comments documentationDavid Goulet2026-01-132-3/+3
| |
| * proto: Seal the VerifiableChannel and FinalizableChannel traitsDavid Goulet2026-01-131-0/+14
| | | | | | | | | | | | They are public but avoid anyone outside implementing them. Signed-off-by: David Goulet <[email protected]>
| * chanmgr: Spawn task for ChannelProvider impl of get_or_launch()David Goulet2026-01-131-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | To pull this off, ChannelProvider::get_or_launch() needed to change from "&self" to "self: Arc<Self>" so we could pass self to the spawned task. This is fine as the caller of ChannelProvider (circuit reactor) has a Arc<ChanMgr>. This also removes the PhantomData for the runtime as we now actually use it. Signed-off-by: David Goulet <[email protected]>
| * proto: Add link_protocol() to VerifiableChannel traitDavid Goulet2026-01-131-0/+6
| | | | | | | | Signed-off-by: David Goulet <[email protected]>
| * chanmgr: Implement tor_proto::ChannelProvider for ChanMgrDavid Goulet2026-01-131-2/+4
| | | | | | | | Signed-off-by: David Goulet <[email protected]>
| * proto: Add traits for public channel viewsDavid Goulet2026-01-131-44/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Add clock_skew() helper to relay unverified channelDavid Goulet2026-01-131-1/+13
| | | | | | | | Signed-off-by: David Goulet <[email protected]>
* | proto: Dedupe IncomingStreamRequestHandlerGabriela Moldovan2026-01-122-31/+8
| |
* | proto: Give IncomingStreamRequestHandler a HopNumGabriela Moldovan2026-01-122-1/+6
|/ | | | | | | | This currently duplicates the client `IncomingStreamRequestHandler`. To deduplicate it, we need the `hop_num` to be optional (it will be `None` for relays, and `Some(hopnum)` in the client reactor). The next commit will fix the code duplication.
* proto: Rename Circuit{Action/Event}::Shutdown to ProtoViolationDavid Goulet2025-12-101-5/+5
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Relay circuit reactor now handles AnyChanMsgDavid Goulet2025-12-103-12/+14
| | | | | | | Same as the client reactor, a message outside of our restricted set leads to a reactor shutdown. Signed-off-by: David Goulet <[email protected]>
* proto: Client circuit reactor now handles AnyChanMsgDavid Goulet2025-12-102-2/+2
| | | | | | | | | | | | | | | 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 RelayCircChanMsg into relay moduleDavid Goulet2025-12-103-4/+3
| | | | | | This follows the move of the client specific object. Signed-off-by: David Goulet <[email protected]>
* proto: Fix relay/hs-service feature gating (fmt)Gabriela Moldovan2025-12-081-1/+1
|
* proto: Fix relay/hs-service feature gatingGabriela Moldovan2025-12-081-1/+1
| | | | | Without this, `tor-proto` doesn't compile if you enable the `relay` feature but not `hs-service`.
* proto: Remove incorrect padding logicGabriela Moldovan2025-12-021-18/+5
| | | | | This was all wrong, as mentioned in https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3487#note_3296033
* proto: Add TODO about our TRUNCATE plansGabriela Moldovan2025-12-021-0/+5
|
* proto: Move EXTEND handling to catch-all errorGabriela Moldovan2025-12-022-9/+0
| | | | | Since EXTEND is not used anymore, it's fine to handle it in our catch-all branch for unrecognized/unsupported cells.
* proto: Explain why we have the backward sink readiness checkGabriela Moldovan2025-12-021-4/+26
|
* proto: Resolve some clippy warnings, remove allowsGabriela Moldovan2025-11-242-6/+3
|
* proto: Reword a nonsensical TODOGabriela Moldovan2025-11-241-3/+15
| | | | | | This TODO was copied over from the client reactor, but it doesn't make any sense here (we don't yet handle control messages in the backward reactor).
* proto: Update relay reactor documentationGabriela Moldovan2025-11-241-8/+79
|
* proto: Fix a number of newly broken doc linksGabriela Moldovan2025-11-241-1/+1
|
* proto: Deduplicate msg_streamid()Gabriela Moldovan2025-11-241-20/+2
| | | | | | | | | | Initially I wanted to turn `msg_streamid()` into a method on `UnparsedRelayMsg`, but I ultimately decided against it, because it feels like it doesn't belong there (even though intuitively, I would've expected it to handle the mismatch between stream ID and cell command internally). This is because all the `UnparsedRelayMsg` methods return `tor_bytes::Result`, and do not actually do any validation beyond some length checks on the various fields.
* proto: Move a couple of stream-related constants to stream mod (fmt)Gabriela Moldovan2025-11-241-1/+1
|
* proto: Move a couple of stream-related constants to stream modGabriela Moldovan2025-11-241-4/+2
|
* proto: Start handling incoming stream requestsGabriela Moldovan2025-11-243-28/+666
| | | | | | | | | | | | | | | | | | | | | | | | | | | The relay reactor is now able to handle incoming stream requests (i.e. cells that open streams). It currently only supports DATA stream requests (BEGIN); support for other stream types (BEGIN_DIR, RESOLVE) will be added later. `Reactor::new()` now returns the futures::Stream of Tor streams, alongside the `Reactor` and `RelayCirc` handle. Whoever calls `Reactor::new()` is responsible for passing the stream of streams over to the task that is meant to handle it ("handle" in this case means either rejecting the stream with a given `END` cell, or accepting it and forwarding the connection between it and the corresponding application stream). IMPORTANT: the above is a bit half-baked! Next on my TODO list is is to iron out the details of how/where this will actually be handled. I am also a bit unsure about the API here: I think it might've been nicer to give the user the ability to obtain this `futures::Stream` from `RelayCirc`, which is, after all, a handle to the reactor? Also on my short-term TODO list is to figure out how conflux will affect this API and usage. And there is another wrinkle here: for incoming DATA stream requests, the handler will need to produce a resulting `DataStream`, which is not yet fully implementation-agnostic (it wraps a `ClientDataStreamCtrl`). This too will be handled in a separate MR.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 06:14:32 +0000