| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
This will be needed for ntor handshakes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
| |
This will be needed for ntor handshakes.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
When used for relay channels, the channel reactor will soon need to
spawn relay circuit reactors.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This object contains a melting pot of public keys, private keys and
certificates.
Rename it to reflect that it is channel authentication material and not
"identities.
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3791#note_3374454
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
No need to call `set_authenticated()` for a relay initiator channel
because relay initiator channel are always authenticated and thus the
underlying channel cell codec will always use the R2R restricted message
set.
This is only useful to a relay responder channel. The naming of that
function is not great actually and should probably change.
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_3374457
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The AUTHENTICATE cell contents depends on all bytes sent on the channel
before the AUTHENTICATE cell itself is sent (the CLOG). So we can only
build a correct AUTHENTICATE cell after the CERTS cell has been sent.
|
| |
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
| |
Rename them to respectively sensitive() and not_sensitive().
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
|
| |
It was all commented out until now that we have a final
RelayIdentities.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
|
|
|
|
| |
For the responder to build the authentication data, it needs its own
certificate of the TLS handshake that it is responding to (as a TLS
server).
This resolves an important TODO(relay) in the code.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
During the channel handshake, we require the peer IP address for the
canonicity check which requires the exact peer IP we are connected to.
This commit adds a function that enforces this requirement on a
ChannelMethod so anything else results in an error.
It is to basically have stronger guarantee on the channel method we use
in the handshake.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
|
|
This commit adds the Unverified and Verified flavor of a relay channel
specific to an initiator.
We decided to use the type system for safety and avoid patterns like:
"if chan.is_initiator() {...} else {...}"
This allows us also to not duplicate code between initiator and
responder code.
The downside is that we expose these types outside of tor-proto meaning
the caller needs to feature gate the usage of these types with the
"relay" flag.
Small price to pay for strong guarantees with the type system.
Signed-off-by: David Goulet <[email protected]>
|
