| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
There are incomplete pieces, marked with "TODO circpad".
There is no integration into the circuit reactor code yet.
Part of #63
|
| |\ \
| |/
|/|
| |
| | |
proto: Refactor channel handshake code for upcoming relay handshake
See merge request tpo/core/arti!3182
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Initiator always know if they will authenticate or not. Responder is
different as a relay doesn't know until the end of the handshake if it
is responding to a relay or a client.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These are following the review of MR 3182. They are put in a single
commit because the git absorb has a large amount of conflicts on rebase
and this commit allows the reviewers to see what happened.
The base branch was rebased on main due to the need for 3184.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| | |
In the spirit of avoidin code duplication.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
All initiator handshake will implement this in order to get access to
the helper function to receive the relay responder cells.
Relay will implement this in future commits.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| |/
|
|
|
|
|
| |
Replaced use of [`static_assertions::const_assert`] with the newly
available "assert in const" pattern.
Signed-off-by: hashcatHitman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
With rustc 1.85, this `expect(unused)` triggers a "lint expectation
unfulfilled" error, because rust thinks the struct *is* used (because of
the d-d `TryFrom` implementation), despite the fact that it's never
actually constructed. This isn't a problem on newer versions (it's
correctly identified as unused/dead code on 1.89, for example).
Using `allow` instead of `expect` is slightly less nice, but it makes
`clippy` pass on 1.85 too.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The `TunnelId*` types will be reused in the relay reactor (exit relays
need to have the concept of a "tunnel ID" because of conflux).
Now the `relay::reactor` module only has a single import from `client`
(for the `unwrap_or_shutdown` helper, which we should be able to remove
soon). From now, we will avoid importing anything from `client` in the
`relay` module, and instead prefer refactoring the code as needed (to
pull the implementation-agnostic parts outside of `client`).
This commit has no functional changes, just code motion.
|
| |
|
|
|
|
|
| |
This is just code motion (I suggest reviewing with `--color-moved`).
This also moves the implementation-agnostic parts from
`tor_proto::client::circuit` to a new `tor_proto::circuit` module.
|
| |\
| |
| |
| |
| | |
proto: Add a new RelayCircChanMsg message subclass.
See merge request tpo/core/arti!3198
|
| | | |
|
| | |
| |
| |
| |
| | |
This will be used to restrict the types of messages that can be sent on
the relay-specific channels.
|
| | |
| |
| |
| |
| | |
This enables us to remove the open-coded implementations in favor of the
derived version.
|
| | |
| |
| |
| |
| |
| | |
The code for generating these is repetitive (see `CreateResponse` and
`ClientChanMsg`), and we will soon need a `RelayChanMsg` type too, so
now is a good time to introduce a helper for generating the boilerplate.
|
| |/ |
|
| |
|
|
|
|
|
|
|
| |
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: tweak docs to say where the prop349 checks are implemented
See merge request tpo/core/arti!3171
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
First of all, VPADDING has been added in link protocol version 3 so it
was missing from v4.
Second, after closely looking at C-tor and the spec, it appears that we
allow VPADDING at any point on a channel which should simply be silently
dropped. Any number in any order.
Third, couple sets were missing the PADDING cell which is only allowed
on an open channel.
Signed-off-by: David Goulet <[email protected]>
|
| | | |
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Use the specification terminology which is also the same for
ChannelType.
Part of #1597
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This type and functions will be used in the handshake process in future
commits.
Part of #1597
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The handler.rs file contains a generic "ChannelCellHandler" which is
split into three different handler depending of the channel state (new,
handshaking or open).
These handlers implement Encoder/Decoder so we can give a
ChannelCellHandler to a asynchronous_codec::Framed along a TLS stream.
That cell handler is also in charge of tracking the CLOG/SLOG (see
tor-spec), running digest of cells seen, which is used to authenticate a
channel for the Relay <-> Relay case.
This ChannelCellHandler auto transitions as the setters function are
used. The handshake code will use this to advance the handler. Each
handler uses a MessageFilter from msg.rs in order to allow or not to
return the message.
A keen eye will notice that we can avoid encoding a message if we don't
need but we will decode all possible messages and only then allow it or
not.
The channel cell handler is not used at this commit.
Part of #1597
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds the code in msg.rs to be able to filter an inbound or outbound
message on a channel.
Each link protocol version implement a "is_allowed()" which is quite
verbose and tests each possibilities for human readability.
Then, we have several small struct/enum that are used to describe how a
message is filtered.
It is still unused at this commit.
Part of #1597
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
To be able to return a crate::Error from the Decoded/Encoder trait, it
needs to implement this conversion.
Part of #1597
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add the msg.rs file containing all the allowed message sets based on the
channel type and direction. They are also namespaced by link protocol
version.
Unused at this commit. They will be used by the channel reactor along
the channel type and link protocol version in order to know if the
message is allowed or not. See is_allowed() helper function in this
commit.
Part of #1597
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| |/
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
| |
This tries to explain that the amount of incoming data we choose to
buffer on an arti stream doesn't really matter for arti's socks proxy,
since the amount of data buffered by the kernel is significantly higher.
|
| | |
|
| |
|
|
| |
This restores the pre-374889d34aa0 behaviour.
|
| |\
| |
| |
| |
| | |
proto: Add a placeholder for the relay reactor.
See merge request tpo/core/arti!3162
|