aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/relay/channel.rs
Commit message (Collapse)AuthorAgeFilesLines
...
* 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-221-2/+2
| | | | | | | 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: 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-221-19/+19
| | | | | | | | | | 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-26/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-221-9/+9
| | | | | | | 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-221-0/+21
| | | | | | | | | | | | | 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-221-3/+10
| | | | | | | | | | | | | | | 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-4/+266
| | | | | | Code movement only. Signed-off-by: David Goulet <[email protected]>
* proto: Add UnverifiedRelayChannel implementationDavid Goulet2025-11-191-0/+14
| | | | | | | | | | | | | | 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: Use Arc for relay identities objectDavid Goulet2025-10-231-1/+3
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Compute authenticate data after validating certificatesDavid Goulet2025-10-231-7/+7
| | | | | | | | | | | | | | 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-0/+36
| | | | | | | | | | 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-0/+50
| | | | | | | | | | | | | | | 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 RelayInitiatorHandshakeDavid Goulet2025-10-231-0/+6
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-27 02:44:10 +0000