| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
| |
The new relay circuit reactor test expect the `PeerInfo` to be populated
with the identity keys of the peer, and won't work without this change.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Because of the sorting requirement and the fact that a `KeyMgr` can have
multiple Ntor keys, the caller now explicitly extract the two Ntor keys
it wants from the `KeyMgr` and then creates a `RelayNtorKeys` object
with them.
Future changes (#2495) will move this into a view and warn if there are
more than 2 keys.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
This will be needed for ntor handshakes.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
| |
The CreateRequestHandler was introduced prior to the relay handshake
unit tests so fix them now that we have a way to build one.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of copying the client unit tests into the channel module, just
make both current unit tests run on a client and relay handshake.
This required a bit of trickery with type HandshakeConnectFn but works
out in the end.
It also adds the RelayMsgBuf that wraps a MsgBuf in order to implement
CertifiedConn which is very relay only.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
Just for mental sanity to have all const at the same place and easily
readable.
No behavior change.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
No behavior change.
Make the const cells public as they will be useful for more upcoming
unit tests especially on the relay side.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| | |
|
| |
|
|
| |
This will be needed for ntor handshakes.
|
| |\
| |
| |
| |
| | |
tor-proto: Move CREATE_FAST handling to a helper
See merge request tpo/core/arti!3869
|
| | |
| |
| |
| |
| | |
Clippy has started warning about this since we moved the CREATE_FAST
handling to a helper, so this resolves that.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
From opara's comment:
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3844#note_3388789
Keep the low level AuthLogDigest type alias and return it. The callsite
is the one deciding if the returned digest is a Clog or a Slog.
Related to #2441
Signed-off-by: David Goulet <[email protected]>
|
| |/
|
|
|
|
|
|
|
| |
Introduce those types in order to avoid mixing them up as the previous
AuthLogDigest was just a type alias over [u8; 32]
Fixes #2441
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| |
|
|
| |
This reverts commit 9c38daf2d3548feca2ff555f5bd52165add0d20c.
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead of giving the `CreateRequestHandler` to the channel after it's
constructed, we integrate it into the handshake so that we can give it
to the channel constructor.
The `ChannelType` is no longer part of the `Channel`.
Some of the tests could be cleaned up slightly now that the channel
doesn't need the `ChannelType`, but I don't want to conflict with !3853.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We can't pass the request handler during the `Channel` constructor since
it would require conditionally compiled function arguments, which aren't
nice.
|
| |
|
|
| |
for handling CREATE* messages on channels.
|
| |
|
|
|
| |
This better fits with existing code that uses `restricted_msg!` and is a
bit more flexible.
|
| |
|
|
|
| |
When used for relay channels, the channel reactor will soon need to
spawn relay circuit reactors.
|
| | |
|
| |
|
|
| |
And rename `CircMap::add_ent()` to `add_origin_ent()`.
|
| | |
|
| | |
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
Mostly, identity a `ChanTarget` as a "target" since we juggle with
PeerInfo and OwnedChanTarget nowadays.
All certificate and keys have very specific names which attempts to
match the spec as much as possible.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
| |
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3791#note_3374476
and
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3791#note_3374478
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
Make read_msg() into a helper and use it accross the handshake code.
No behavior change.
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3791#note_3374466
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
We can remove the "/* take_slog */ true" pattern and instead have an
explicit type at the callsite for semantic.
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3791#note_3374457
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
| |
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3791#note_3374457
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| |
|
|
| |
Typos found with codespell
|
| |
|
|
|
|
| |
In other words kp_relaysign_ed.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
| |
The responder channel will soon use it.
Signed-off-by: David Goulet <[email protected]>
|