aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/channel/handshake.rs
Commit message (Collapse)AuthorAgeFilesLines
...
* proto: Introduce a ChannelBaseHandshake traitDavid Goulet2025-09-021-37/+96
| | | | | | | | | | | | | | | | Client and relay handhsake share a lot of code because they both send/recv the same cells, just handles them differently for verification. This is the base trait for all handshake implementing basic getters and VERSIONS cell handling. This will allow the RelayInitiatorHandshake and RelayResponderHandshake to use this common code. See, traits are fun. Win-win-win. Signed-off-by: David Goulet <[email protected]>
* proto: Put in a ChannelFrame<T> into the client handshakeDavid Goulet2025-09-021-10/+9
| | | | | | | | | | | | The ClientInitiatorHandshake holds a "tls" sink but the very first thing we do is transform it to a ChannelFrame<T>. Instead, just store the frame to the object directly so we can then use a channel frame uniformily accross its lifetime. This will be useful for the future refactoring paving the way for relay channel authentication. Signed-off-by: David Goulet <[email protected]>
* proto: Only allow VERSIONS cell for the new handshake stateDavid Goulet2025-08-271-20/+7
| | | | | | | | | Due to this, it is not possible to get a VPADDING before because it requires a link protocol version to decideon the encoding: https://gitlab.torproject.org/tpo/core/torspec/-/issues/366 Signed-off-by: David Goulet <[email protected]>
* proto: Remove the AUTHORIZE as a parsable cellDavid Goulet2025-08-211-15/+1
| | | | | | | | | | | | | The AUTHORIZE cell command is simply reserved but not defined. The tor specification, at this point in time, is allowing such cell before the handshake starts but it is very unclear on what ordering is allowed nor how many can are allowed. C-tor silents drop them like VPADDING and so clearly unused. Instead of dealing with it, simply remove its support but keeping its reserved number. Signed-off-by: David Goulet <[email protected]>
* proto: Return AUTHORIZE, VPADDING and VERSIONS at handshakeDavid Goulet2025-08-211-9/+37
| | | | | | | | When starting a handshake, we were only expecting a VERSIONS which is not what the protocol say. An AUTHORIZE and VPADDING can arrive before a VERSIONS. Signed-off-by: David Goulet <[email protected]>
* proto: Rename OutboundClientHandshakeDavid Goulet2025-08-201-6/+6
| | | | | | | | | Use the specification terminology which is also the same for ChannelType. Part of #1597 Signed-off-by: David Goulet <[email protected]>
* proto: Make the OutboundClientHandshake use new cell handlerDavid Goulet2025-08-201-112/+52
| | | | | | | | | | | | | | | | | Use the ChannelFrame<> for the entirety of the outbound client handshake that is the ClientInitiator channel type. With this change, the codec.rs code is not needed anymore along its CodecError as well which has been normalized onto the crate::Error instead in order to simplify error handling and avoid duplication of error types. Unit tests have been modified to reflect this change of what can be done with a channel frame. Also renamed to focus on client behavior. Part of #1597 Signed-off-by: David Goulet <[email protected]>
* proto: Add ChannelType enumDavid Goulet2025-08-201-1/+10
| | | | | | | | | | | | | | | | The ChannelType indicates the type of channel in order to dictate which message is allowed on it. The value use the Initiator and Responder terminology from tor-spec documents. At this commit, we only have client channel meaning the "ClientInitiator" type. In future commits, the channel type will be used by the channel reactor to restrict which message is allowed or not. Part of #1597 Signed-off-by: David Goulet <[email protected]>
* Switch Cargo.toml files to edition 2024.Nick Mathewson2025-08-071-16/+24
| | | | | | | | | | | | | | First, run ``` git grep -l "^edition =" | xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;' ``` Second, manually verify that all Cargo.toml files have changed, and nothing else has changed. Third, run cargo fmt again.
* tor-proto: Log channel, circuit, stream identifiers as structured fields.Gabriela Moldovan2025-06-121-15/+17
| | | | | | | | | | | | | | | | | This changes the `tor-proto` logs to not be prefixed with a channel/circuit/stream ID, but rather to have these IDs attached to the log as structured fields. This change is in preparation for the switch to using `TunnelId`s in the tunnel reactor instead of circuit `UniqId`s. The reason for the change to use structured fields is because future logs will likely need to log the `UniqId`s of the circuits in a tunnel, which will need to either be formatted somehow in the logs, or logged as a structured field (the latter seems like the better option, hence this preparatory change). IMO we should favor structured fields over formatted strings in the logs in general, but that is a bigger project, so I am only doing a spot fix for now.
* tor-proto: remove `use asynchronous_codec as futures_codec`Neel Chauhan2025-02-061-4/+4
| | | | Closes #1690.
* tor-proto: Pass a StreamOps handle to the channel reactor.Gabriela Moldovan2025-01-151-0/+8
|
* tor-rtcompat: Big invasive change adding StreamOps bound everywhere.Gabriela Moldovan2025-01-151-10/+16
| | | | | | This is unfortunately necessary, because after the channel handshake, we need to give the channel reactor a `StreamOps` handle to the underlying stream.
* tor-proto: Plumb the ChannelAccount through to queue creation siteIan Jackson2024-10-031-4/+20
| | | | | This gets it as far as the outbound circuit->channel mpsc queue creation. Also, we provide an accessor for it.
* tor-proto: Plumb the ChannelAccount through to queue creation site (pre-fmt)Ian Jackson2024-10-031-1/+5
|
* tor-proto: channel: Make construction fallibleIan Jackson2024-10-031-2/+2
| | | | | Making a channel is going to involve making a memquota Participant, which can fail.
* tor-proto: Add a CoarseTimeProvider bound to all the SleepProviders (fmt)Ian Jackson2024-10-011-4/+14
|
* tor-proto: Add a CoarseTimeProvider bound to all the SleepProvidersIan Jackson2024-10-011-8/+8
| | | | | | | The memquota arranagements are going to use this. We *don't* apply this to Channel (or to other types that aren't already generic over SleepProvider).
* UnverifiedChannel: Clarify check's peer_certClara Engler2024-07-111-1/+1
| | | | | | | This commit clarifies the documentation of the `peer_cert` parameter in the `UnverifiedChannel::check` function, in order to reflect that it represents the certificate presented during the ServerHello in the TLS handshake and not in the in-protocol CERTS cell.
* proto: Make Channel explicitly Arc<.>Nick Mathewson2024-05-161-1/+1
| | | | | | | | | | | | | | | | Previously, Channel was a type that you could Clone that implicitly its state. Now, Channel always appears as an Arc<Channel>. This change has several benefits: * It makes the relationship between Channel struct and the underlying channel more clear. * It enables Channel to participate in the RPC system, where everything has to be an Arc<.> * It enables us to have a Weak<Channel>, if we ever want to. * It will let us move various members out of ChannelDetails. We did this change a while ago with ClientCirc.
* clippy: Replace many calls to .get(0) with .first()Ian Jackson2024-01-021-1/+1
| | | | | FTR I don't think agree with clippy on this question, but then I often don't.
* test: add a test for missing NETINFO cellsEmil Engler2023-08-121-0/+15
| | | | | | This commit adds a unit test to the `tor_proto::handshake` module, which tests the behavior when no NETINFO cell is present within a channel.
* tor-proto: Remove use of arrayref.Nick Mathewson2023-06-011-2/+5
|
* Replace usage of KeyUnknownCert::check_key.Nick Mathewson2023-05-161-2/+2
|
* tor-proto: only parse allowed ChanMsg types during handshake.Nick Mathewson2023-02-091-14/+26
|
* tor-cell: Rename ChanMsg and ChanCell-related types.Nick Mathewson2023-02-071-2/+2
|
* tor-cell: Remove ChanMsg methods that are duplicated in ChanMsgClass.Nick Mathewson2023-02-071-1/+1
|
* tor-cell: Use macro to generate ChanMsg too.Nick Mathewson2023-02-071-1/+1
|
* tor-proto: rustfmtIan Jackson2023-01-061-1/+2
| | | | Not sure why the tree didn't have this newline already. "Whatever".
* tor-proto: When relay IDs mismatch, the IDs are sensitive in errorsIan Jackson2023-01-061-2/+4
|
* Use parse_rfc3339() in the tor-proto crateNeel Chauhan2022-12-161-1/+2
|
* Tackling issue #663 (Use humantime in tests)coral2022-12-121-1/+1
|
* Merge branch 'rename_for_to_from' into 'main'Nick Mathewson2022-10-251-2/+2
|\ | | | | | | | | tor-cell: Rename for_client and for_relay See merge request tpo/core/arti!793
| * tor-cell: Rename for_client and for_relayEmil Engler2022-10-211-2/+2
| | | | | | | | | | | | | | This commit renames the for_client and for_relay functions to from_client and from_relay respectively, in order to indicate their origin, as the term "for" is more likely to indicate a destination, which is not true in that situation.
* | linkspec: Remove now-useless declared_peer_addrNick Mathewson2022-10-241-3/+4
|/ | | | The singleton variation here is almost never what we want.
* Change multiplicity of ChannelMethod and addressesNick Mathewson2022-10-111-2/+2
| | | | | | | Now each `ChanTarget` has at most one `ChannelMethod`, and only `Direct` `ChannelMethods` can have multiple addresses. Closes #600.
* Clarify limits on socket address from ChannelMethodNick Mathewson2022-10-061-2/+2
|
* tor-linkspec: Remove the old OwnedFoo::new() functionsNick Mathewson2022-10-061-4/+10
| | | | These are now builders.
* tor-proto: Preserve the ChannelMethod, not the SocketAddrNick Mathewson2022-10-061-21/+42
|
* channel padding: Properly advertise link protocol 5Ian Jackson2022-08-171-3/+2
| | | | | | | | | We already actually send and negotiate the padding, since !657, but we ought to negotiate a protocol version where that's not a violation! As per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2828354
* tor-proto: Unify the check_match code in channel and handshakeNick Mathewson2022-08-101-27/+15
| | | | | | | | | | This had to become a new internal function, since at the point that the handshake needs this code, it does not yet have a Channel to use. This change made the error messages in the handshake code more informative: and now they require a regex to check. Later, we might want to defer formatting these strings, but I don't think we need to do it now.
* Final (?) API revisions for tor-linkspecNick Mathewson2022-08-101-10/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With this change, each individual identity type becomes optional. The functions that expose them unconditionally are now in a "legacy" trait that only some downstream types are expected to implement. There are new convenience APIs in HasRelayIds: * to return Option<&keytype>, * to see if one identity-set contains another. This commit will break several downstream crates! For the reviewer's convenience, I will put the fixes for those crates into a series of squash! commits on this one. tor-netdir ---------- Revise tor-netdir to accept optional identities. This required some caveats and workarounds about the cases where we have to deal with a key type that the tor-netdir code does not currently recognize at all. If we start to add more identity types in the future, we may well want more internal indices in this code. tor-proto --------- In order to make tor-proto support optional identities, there were fewer changes than I thought. Some "check" functions needed to start looking at "all the ids we want" rather than at "the two known IDs"; they also needed to accommodate that case where we don't have an ID that we demand. This change will also help with bridges, since we want to be able to connect to a bridge without knowing all of its IDs up front. The protocol currently _requires_ the two current ID types in some places. To deal with that, I added a new `MissingId` error. I also removed a couple of unconditional identity accessors for chanmgr; code should use `target().identity(...)` instead. tor-chanmgr ----------- This is an incomplete conversion: it does not at all handle channel targets without Ed25519 identities yet. It still uses those identities to index its internal map from identity to channel; but it gives a new `MissingId` error type if it's given a channel target that doesn't have one. We'll want to revise the map type again down the road when we implement bridges, but I'd rather not step on the channel-padding work in progress right now. tor-guardmgr ------------ This change is mostly a matter of constructing owned identity types more sensibly, rather than unwrapping them directly. There are some places marked with TODOs where we still depend on particular identity types, because of how the directory protocol works. This will need revisiting when we add bridge support here. tor-circmgr ----------- These changes are just relatively simple API changes in the tests.
* Remove some testing-only reimplementations of OwnedChanTarget.Nick Mathewson2022-08-021-17/+1
| | | | These predate OwnedChanTarget, and are no longer needed.
* change usage of PublicKey to Ed25519 in tor-certtrinity-1686a2022-07-231-5/+3
| | | | and propagate to other affected crates
* change check_key to take a Option<&_> instead of &Option<_>trinity-1686a2022-07-231-2/+2
|
* tor-cell: Make encoding method signatures fallible.Nick Mathewson2022-07-111-1/+5
|
* tor-proto: split and elaborate tor_bytes::Error instancesNick Mathewson2022-06-231-5/+14
| | | | | | | | | Some of these were for decoding particular objects (we now say what kind of objects), and some were unrelated tor_cert errors that for some reason we had shoved into a tor_bytes::Error. There is now a separate tor_cert::CertError type, independent from tor_cert's use of `tor_bytes::Error` for parsing errors.
* tor-proto: Split CellErr based on activity.Nick Mathewson2022-06-231-2/+6
| | | | | | Failing to encode is fundamentally different from failing to decode. We now treat those separately, and describe _what_ we failed to encode or decode.
* tor-proto: clean up error names and messagesNick Mathewson2022-06-231-13/+13
| | | | | This avoids adding additional information for now; that will come on the next commits.
* Plumb a SleepProvider into the channel reactorIan Jackson2022-06-081-34/+77
| | | | | The channel reactor is going to want to be able to sleep so that it can do padding, so it needs a SleepProvider.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 03:47:12 +0000