aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/relay/channel
Commit message (Collapse)AuthorAgeFilesLines
...
* 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.
* safelog: Rename MaybeSensitive::hidden/visible()David Goulet2026-03-032-3/+4
| | | | | | Rename them to respectively sensitive() and not_sensitive(). Signed-off-by: David Goulet <[email protected]>
* proto: Channel handshake minor cleanupDavid Goulet2026-03-031-3/+5
| | | | | | | | | | To make the code a bit better here. Also, at this commit, the UnverifiedChannel::finish() and VerifiedChannel::finish() are basically the exact same. A refactoring to use a finish() helper would work nicely. Signed-off-by: David Goulet <[email protected]>
* proto: Setup the channel PeerInfo in the specialized finish()David Goulet2026-03-032-7/+19
| | | | | | | | | | | 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: Make channel PeerAddr sensitiveDavid Goulet2026-03-032-11/+14
| | | | | | | 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-252-8/+3
| | | | | | | 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-193-13/+16
| | | | | | | | | | 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-193-31/+17
| | | | | | | 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]>
* relay: Pass our TLS cert to the responder verify processDavid Goulet2026-02-122-2/+14
| | | | | | | | | | For the responder to build the authentication data, it needs its own certificate of the TLS handshake that it is responding to (as a TLS server). This resolves an important TODO(relay) in the code. Signed-off-by: David Goulet <[email protected]>
* proto: Enforce that channel method as unique SocketAddrDavid Goulet2026-02-122-22/+11
| | | | | | | | | | | | | During the channel handshake, we require the peer IP address for the canonicity check which requires the exact peer IP we are connected to. This commit adds a function that enforces this requirement on a ChannelMethod so anything else results in an error. It is to basically have stronger guarantee on the channel method we use in the handshake. Signed-off-by: David Goulet <[email protected]>
* proto: Channel finish() now handles canonicityDavid Goulet2026-02-123-19/+56
| | | | | | | | | | | | | | 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: Relay responder channel allow to be non_exhaustiveDavid Goulet2026-02-091-1/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Publicly re-export MaybeVerifiableRelayResponderChannelDavid Goulet2026-02-091-0/+1
| | | | | This type is needed in the tor-chanmgr crate in order to decide to verify or not the underlying relay channel.
* proto: Add missing clock_skew() to unverified channelsDavid Goulet2026-02-042-2/+12
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Introduce new relay responder channel typesDavid Goulet2026-02-042-20/+210
| | | | | | | | | | 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-042-4/+187
| | | | | | | | | | | | | | | | | | | 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]>
* proto: Move comment in relay handshake.rsDavid Goulet2025-11-191-1/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Implement part of UnverifiedRelayChannel::finish()David Goulet2025-11-191-10/+37
| | | | | | | | | | The UnverifiedChannel::finish() was split in previous commit so this adds the support for sending the right NETINFO cell instead of the client specific one. Added more TODOs for followup commits. Signed-off-by: David Goulet <[email protected]>
* proto: Add VerifiedRelayChannel implementationDavid Goulet2025-11-191-1/+31
| | | | | | | | 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-17/+86
| | | | | | | | | | | | | | 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]>
* proto: Introduce relay specific channel structsDavid Goulet2025-11-191-2/+38
| | | | | | | | | | The new UnverifiedRelayChannel and VerifiedRelayChannel struct are added to decouple the client code and put the relay component in its module. Both objects hold the to become generic object that both client and relay will use to create a channel. Signed-off-by: David Goulet <[email protected]>
* proto: Remove relay ChannelAuthenticationData builderDavid Goulet2025-10-231-64/+11
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Use Arc for relay identities objectDavid Goulet2025-10-231-3/+3
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Remove LOG_PREFIX in relay handshakeDavid Goulet2025-10-231-5/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Compute authenticate data after validating certificatesDavid Goulet2025-10-231-2/+1
| | | | | | | | | | | | | | 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 a relay channel builderDavid Goulet2025-10-231-1/+0
| | | | | | | | | | The client and relay channel builder don't share anything and return different objects hence the seperation. Furthermore, this seperation avoids having the client ChanMgr ability to launch relay channels. Signed-off-by: David Goulet <[email protected]>
* proto: Add RelayIdentities object holding our keysDavid Goulet2025-10-231-1/+11
| | | | | | | | | | | | | | | This is a intermediary object between tor-chanmgr and tor-proto that is when building a relay channel, those keys/certs need to be set in the ChannelBuilder so the tor-proto can use them to authenticate. We avoid that way making tor-proto depending on tor-keymgr for the ultimate goal to avoid tor-proto to have access to all the keys in the KeyMgr. Future commits will introduce a relay channel builder which will use that object to set the keys. Signed-off-by: David Goulet <[email protected]>
* proto: Add the channel authentication dataDavid Goulet2025-10-231-2/+147
| | | | | | | | | | | This commit only adds a struct holding all the authentication data that needs to be built during the verification process after all handshake cells needed for authentication have been sent. It lives in the VerifiedChannel struct so it can be used to build the AUTHENTICATE cell and be sent before the NETINFO. Signed-off-by: David Goulet <[email protected]>
* proto: Add RelayInitiatorHandshakeDavid Goulet2025-10-231-0/+126
This implements the relay initiator side of the handshake up to the creation of an unverified channel. Signed-off-by: David Goulet <[email protected]>
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 22:51:42 +0000