summaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/channel
Commit message (Collapse)AuthorAgeFilesLines
* tor-proto: Port to web-time-compatNick Mathewson2026-03-262-6/+6
|
* Fix typosTobias Stoeckmann2026-03-243-4/+4
| | | | Typos found with codespell
* proto: The relay signing key signs the auth certDavid Goulet2026-03-191-3/+3
| | | | | | In other words kp_relaysign_ed. Signed-off-by: David Goulet <[email protected]>
* tor-proto: fix the relay initiator's SLOG digestSteven Engler2026-03-191-3/+23
|
* tor-proto: improve chan send/recv-log error messagesSteven Engler2026-03-191-2/+6
|
* proto: Set the link protocol outside the recv VERSIONS helperDavid Goulet2026-03-191-3/+9
| | | | | | | | | | | | | | | | | | | 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: Fix unit testsDavid Goulet2026-03-191-7/+17
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Improve logging in channel handshakeDavid Goulet2026-03-191-2/+2
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Add specialized build functions for ChannelAuthenticationDataDavid Goulet2026-03-191-8/+1
| | | | | | | | | | | The initiator and responder are quite different. Building an AUTHENTICATE cell is delicate and so this change differenticates clearly between the two. This allows us to remove the peer_cert_digest from an UnverifiedChannel which is only something that makes sense for an initiator. Signed-off-by: David Goulet <[email protected]>
* proto: New UnverifiedInitiatorChannelDavid Goulet2026-03-191-66/+109
| | | | | | | | 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-81/+14
| | | | | | | | | | | | | | | | | | | | | | | | 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]>
* proto: Add the verify_link_auth_cert() helperDavid Goulet2026-03-191-1/+57
| | | | | | The responder channel will soon use it. Signed-off-by: David Goulet <[email protected]>
* proto: Use RelayIds in a VerifiedChannelDavid Goulet2026-03-191-59/+37
| | | | | | | | | | | | | | | | In order to pull this off, make UnverifiedChannel::check_relay_identities() to return a RelayIds that it builds after checking if they match the peer we were expecting. This part is moved in this commit so once check_relay_identities() returns, we are certain of the relay identity validity on both "it identified properly" and "it is the right expected relay". This makes it that the check_relay_identities() returns the RelayIds, the signing key and the RSA id digest (which is needed for authentication later). Signed-off-by: David Goulet <[email protected]>
* proto: Move into a helper function the TLS cert validationDavid Goulet2026-03-191-28/+61
| | | | | | | | | | This introduces verify_tls_cert() standalone function. It is such because both client and relay initiator will use it. For now, the check_internal() has been modified to use it. We are slowly building towards having specialized check function per channel type. Signed-off-by: David Goulet <[email protected]>
* proto: Split relay identity checks from CERTS into its own functionDavid Goulet2026-03-191-90/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a loaded commit, apologize in advance but not many way around this. One thing that is generic to all verifiable channel (authenticated) is that they all need to check the relay identities and signing key from the CERTS cell. This commits extracts that part into UnverifiedChannel::check_relay_identities() which returns those said identities and the signing key (KP_relaysign_ed). The signing key is actually needed for only one context, the initiator part because the TLS cert is signed with it. The LINK AUTH cert is signed by the ed25519 identity key itself which is what the responder will look for. This commit has two side effects which I believe are OK: 1. The timeliness check of the identity certs is now done prior to the other cert (TLS/LINK). 2. We no longer check signatures in batch mode as we can't batch ed25519 sig check with the RSA crosscert sig. It appears the batch validation was there for performance and not for security purposes. The end goal of this piece of work is that the specialized channel will start by calling a generic check function that will call check_relay_identities(). And then, the secondary certificates will get checked depending on the side of the channel. Expect also a variable rename commit at the end as the naming in this function is really bad. Signed-off-by: David Goulet <[email protected]>
* proto: Extract inline helpers into struct itselfDavid Goulet2026-03-191-40/+46
| | | | | | | | | | | Move two inline functions located in UnverifiedChannel::check_internal() into the UnverifiedChannel object itself. Laying down the ground work for the more specialized objects to use those as the check_internal() is about to get massively refactored into more specific channel types. 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-16/+10
|
* tor-proto: improve error messages during handshakeSteven Engler2026-03-031-4/+5
|
* tor-proto: during handshake ensure circ id is 0Steven Engler2026-03-031-2/+9
|
* tor-proto: require cells from responder to be orderedSteven Engler2026-03-031-60/+97
|
* tor-proto: make receiving AUTH_CHALLENGE non-optionalSteven Engler2026-03-031-4/+3
|
* tor-proto: remove `is_expecting_auth_challenge()`Steven Engler2026-03-031-6/+1
| | | | The responder always sends an AUTH_CHALLENGE cell.
* tor-proto: send an AUTH_CHALLENGE during testsSteven Engler2026-03-031-0/+2
| | | | | | | As far as I know, a responder will always send an AUTH_CHALLENGE cell since it doesn't yet know if the initiator is a client or relay. The spec also doesn't have any mention about the AUTH_CHALLENGE being optional. So we should send it in our tests as well.
* safelog: Rename MaybeSensitive::hidden/visible()David Goulet2026-03-032-4/+7
| | | | | | Rename them to respectively sensitive() and not_sensitive(). Signed-off-by: David Goulet <[email protected]>
* linkspec: Implement a RelayIdsBuilder::from_relay_ids()David Goulet2026-03-031-6/+2
| | | | | | | | | This is used when we build an OwnedChanTarget using the builder. Instead of going identities by identities at the callsite, we can use this helper to get us a RelayIds builder and set it in the OwnedChanTargetBuilder. Signed-off-by: David Goulet <[email protected]>
* proto: Channel handshake minor cleanupDavid Goulet2026-03-031-5/+6
| | | | | | | | | | 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-49/+40
| | | | | | | | | | | 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-031-3/+6
| | | | | | | 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]>
* tor-proto: rename 'SLOG'/'CLOG' and related codeSteven Engler2026-03-021-48/+76
|
* Merge branch 'relay-channel-fixes' into 'main'David Goulet2026-02-261-0/+4
|\ | | | | | | | | relay: Couple fixes related to channel creation See merge request tpo/core/arti!3726
| * proto: Add 'CreateFast/CreatedFast' to relay message filterSteven Engler2026-02-261-0/+4
| |
* | proto: The AUTHENTICATE cell requires the SHA256 RSA identity digestDavid Goulet2026-02-261-8/+14
|/ | | | | | | Before this commit, we would use the RsaIdentity which is a SHA1 digest. We do the same for the peer RSA key. Signed-off-by: David Goulet <[email protected]>
* tor-proto: improve debug tracing messageSteven Engler2026-02-241-2/+2
| | | | | | | | | | | | | | Before: ```text Completed handshake with Ed25519Identity { ClByyE4zT+p3dudeCVkUfVA1zp2y2sOUe7u/HHLliWU } [(RsaIdentity { $547bb37f9cd8079eaf1cfcb73fff5887d6f58138 }, [9, 111, 131, 62, 212, 144, 149, 88, 211, 87, 175, 114, 18, 111, 189, 36, 205, 21, 66, 205, 217, 176, 139, 130, 70, 211, 40, 130, 79, 29, 144, 179])] ``` After: ```text Completed handshake with ed25519:wo9NA5RXkPAc7sB2301JBpvdk1RvSOGZEzgwuWP/msA [$feebaba2b6faf53ae1dc8dda8681ce026537dfa4] ```
* tor-proto: split field into two fieldsSteven Engler2026-02-241-6/+10
| | | | | These were previously in a single `Option`, but now that the `Option` was removed, I think it's nicer to make these separate fields.
* tor-proto: remove unnecessary `Option`sSteven Engler2026-02-241-14/+8
| | | | | | I don't think that the `Option`s are needed anymore, since unauthenticated channels no longer transition through the `VerifiedChannel` state.
* proto: Filter the IP address in the channel's OwnedChanTargetDavid Goulet2026-02-191-23/+35
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Reuse the RelayIds builder during the handshakeDavid Goulet2026-02-191-18/+11
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Pass PeerAddr at the channel handshake finish for initiatorsDavid Goulet2026-02-191-38/+13
| | | | | | | | | | 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 constructor for PeerInfo instead of BuilderDavid Goulet2026-02-191-15/+10
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Remove Default of PeerInfo/Addr and use const insteadDavid Goulet2026-02-192-9/+25
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Put a PeerInfo in ChannelDavid Goulet2026-02-192-2/+31
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Use the PeerAddr accross channel handshakeDavid Goulet2026-02-191-7/+20
| | | | | | | 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-122-5/+20
| | | | | | | | | | | | | | 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]>
* Merge branch 'unused-async-lint' into 'main'gabi-2502026-01-281-2/+3
|\ | | | | | | | | | | | | maint/add_warning: Deny clippy::unused_async Closes #2328 See merge request tpo/core/arti!3613
| * proto: Add an exception for clippy::unused_asyncGabriela Moldovan2026-01-271-0/+1
| |
| * proto: Remove unnecessary async in channel reactorGabriela Moldovan2026-01-271-2/+2
| | | | | | | | | | This resolves a warning triggered by the newly-introduced `#[deny(clippy::unused_async)]`.
* | clippy: Fix missing doc for non-Linux buildsClara Engler2026-01-271-0/+1
|/
* proto: Add missing use for testsDavid Goulet2026-01-221-1/+1
| | | | Signed-off-by: David Goulet <[email protected]>
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 07:41:18 +0000