aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/relay/channel/handshake.rs
Commit message (Collapse)AuthorAgeFilesLines
* Upgrade rand crates to 0.10.Wesley Aptekar-Cassels2026-05-121-1/+1
| | | | | | | | | | | When the circ-padding feature is enabled, we use maybenot, which does not yet support rand 0.10. In the meantime, enabling this feature pulls in rand 0.9. This is not ideal, but should be okay as a temporary situation. This also replaces the use of ReseedingRng (which was removed in 0.10) with the reseeding_rng crate. This is somewhat less performant, but it should be okay.
* tor-proto: give our rsa ident to the channel reactorSteven Engler2026-04-161-0/+1
| | | | This will be needed for ntor handshakes.
* tor-proto: give our ed ident to the channel reactorSteven Engler2026-04-091-0/+1
| | | | This will be needed for ntor handshakes.
* relay: Pass advertise SocketAddr to channel builder instead of IpAddrDavid Goulet2026-04-091-5/+5
| | | | | | | | | | This trickles down to the tor-proto channel handshake code. But, the real need is in the channel builder in order to validate the outbound channel target. Fixes #2440 Signed-off-by: David Goulet <[email protected]>
* proto: Bring back AuthLogDigest and explicitly convert to SLOG/CLOGDavid Goulet2026-04-081-10/+3
| | | | | | | | | | | | From opara's comment: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3844#note_3388789 Keep the low level AuthLogDigest type alias and return it. The callsite is the one deciding if the returned digest is a Clog or a Slog. Related to #2441 Signed-off-by: David Goulet <[email protected]>
* proto: Add ClogDigest and SlogDigest typesDavid Goulet2026-04-081-5/+13
| | | | | | | | | Introduce those types in order to avoid mixing them up as the previous AuthLogDigest was just a type alias over [u8; 32] Fixes #2441 Signed-off-by: David Goulet <[email protected]>
* tor-{proto,chanmgr}: change how channels accept a CREATE* handlerSteven Engler2026-04-081-0/+12
| | | | | | | | | | | 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.
* proto: Import read_msg() instead of refering to itDavid Goulet2026-03-301-19/+4
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Rename RelayIdentities to RelayChannelAuthMaterialDavid Goulet2026-03-301-10/+10
| | | | | | | | | | | | This object contains a melting pot of public keys, private keys and certificates. Rename it to reflect that it is channel authentication material and not "identities. https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3791#note_3374454 Signed-off-by: David Goulet <[email protected]>
* proto: Rename many variables with more fine grained namingDavid Goulet2026-03-301-2/+2
| | | | | | | | | | Mostly, identity a `ChanTarget` as a "target" since we juggle with PeerInfo and OwnedChanTarget nowadays. All certificate and keys have very specific names which attempts to match the spec as much as possible. Signed-off-by: David Goulet <[email protected]>
* proto: Remove duplicate use of read_msg() helperDavid Goulet2026-03-301-45/+21
| | | | | | | | | | Make read_msg() into a helper and use it accross the handshake code. No behavior change. https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3791#note_3374466 Signed-off-by: David Goulet <[email protected]>
* proto: Fix a set of commentsDavid Goulet2026-03-301-2/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Add AuthLogAction enum helperDavid Goulet2026-03-301-5/+4
| | | | | | | | | We can remove the "/* take_slog */ true" pattern and instead have an explicit type at the callsite for semantic. https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3791#note_3374457 Signed-off-by: David Goulet <[email protected]>
* proto: Add a type alias for SLOG/CLOG digestDavid Goulet2026-03-301-7/+3
| | | | | | https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3791#note_3374457 Signed-off-by: David Goulet <[email protected]>
* tor-proto: Port to web-time-compatNick Mathewson2026-03-261-2/+2
|
* tor-proto: fix the relay responder's CLOG/SLOG digestsSteven Engler2026-03-191-12/+31
|
* tor-proto: fix the relay initiator's SLOG digestSteven Engler2026-03-191-2/+8
|
* proto: Set the link protocol outside the recv VERSIONS helperDavid Goulet2026-03-191-14/+13
| | | | | | | | | | | | | | | | | | | It used to work for an initiator to set the link protocol once a VERSIONS is received because initiator send their VERSIONS before. This failed with responders because a responder channel sends their VERSIONS after receiving one from the initiator. This reverse logic means that the channel cell handler was transitionned to the Handshake state before a responder was able to send a VERSIONS cell leading to a failure because VERSIONS cell aren't allowed at the Handshake state. To fix this, the send/recv or recv/send is now explicit per channel type and once this is done and successful, the link protocol is set. A `set_link_protocol()` is added to the ChannelBaseHandshake trait so it can be used to set the cell handler. Signed-off-by: David Goulet <[email protected]>
* proto: New UnverifiedInitiatorChannelDavid Goulet2026-03-191-10/+13
| | | | | | | | Both client and relay specialized channel now use it as their inner base channel so they can use the same common verify() function since it is the same validation for both. Signed-off-by: David Goulet <[email protected]>
* proto: Move cert validation per specialized channelDavid Goulet2026-03-191-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | Remove the last part from check_internal() that is specific to an initiator channel. At this commit, all three specialized channel do the verify process within their own verify() function. The client and relay initiator both look at the TLS cert (code duplication unfortunately). And the relay responder looks at the LINK_AUTH cert extracting the peer KP_link_ed key for validation. The CERTS cell is removed from UnverifiedChannel as it is now only useful within the verification process which is now specialized. A series of TODO(relay) is added to point out the current problem and how to fix them. The next step is to create an UnverifiedInitiatorChannel that will hold the verity_tls_cert() function and peer cert information which is only relevant to an initiator. This will remove code duplication. Signed-off-by: David Goulet <[email protected]>
* tor-cell: rename `RestrictedMsg::restricted_cmds()` to `cmds_for_logging()`Steven Engler2026-03-041-1/+1
|
* tor-proto: small code cleanupSteven Engler2026-03-031-9/+3
|
* tor-proto: improve error messages using `RestrictedMsg`Steven Engler2026-03-031-19/+7
|
* tor-proto: improve error messages during handshakeSteven Engler2026-03-031-1/+2
|
* tor-proto: during handshake ensure circ id is 0Steven Engler2026-03-031-2/+9
|
* tor-proto: require cells from initiator to be orderedSteven Engler2026-03-031-61/+112
|
* tor-proto: make receiving AUTH_CHALLENGE non-optionalSteven Engler2026-03-031-4/+0
|
* tor-proto: remove `is_expecting_auth_challenge()`Steven Engler2026-03-031-4/+0
| | | | The responder always sends an AUTH_CHALLENGE cell.
* proto: Make channel PeerAddr sensitiveDavid Goulet2026-03-031-7/+9
| | | | | | | Only the R2R channel that the PeerAddr becomes unsensitive. The rest, we keep it sensitive as it can be a client or a client's guard/bridge. Signed-off-by: David Goulet <[email protected]>
* proto: Implement the build_certs_cell() helperDavid Goulet2026-02-251-6/+1
| | | | | | | It was all commented out until now that we have a final RelayIdentities. Signed-off-by: David Goulet <[email protected]>
* proto: Pass PeerAddr at the channel handshake finish for initiatorsDavid Goulet2026-02-191-6/+2
| | | | | | | | | | 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-191-5/+11
| | | | | | | 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]>
* proto: Channel finish() now handles canonicityDavid Goulet2026-02-121-3/+12
| | | | | | | | | | | | | | 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: Introduce new relay responder channel typesDavid Goulet2026-02-041-20/+34
| | | | | | | | | | 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-041-4/+9
| | | | | | | | | | | | | | | | | | | 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: 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: Use the channel codec channel typeDavid Goulet2026-01-221-4/+0
| | | | | | | | | | | | | | | | | 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: Remove Option<> around peer_ip for build_netinfo_cell()David Goulet2026-01-221-1/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Avoid magic hardcoded value for LINK_AUTHDavid Goulet2026-01-221-1/+1
| | | | | | | 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: Send relay channel NETINFO in check()David Goulet2026-01-221-0/+6
| | | | | | | | | | 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-221-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Add CertifiedConn to relay handshakeDavid Goulet2026-01-221-8/+8
| | | | | | | 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: Implement RelayResponderHandshakeDavid Goulet2026-01-221-2/+243
| | | | | | | | | | | | | 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: Make CERTS cell optionnable for UnverifiedChannelDavid Goulet2026-01-221-1/+1
| | | | | | | | | | | | | | | 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-221-265/+6
| | | | | | Code movement only. Signed-off-by: David Goulet <[email protected]>
* 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]>
* proto: Add link_protocol() to VerifiableChannel traitDavid Goulet2026-01-131-0/+6
| | | | 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]>
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 05:51:06 +0000