| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
When the circ-padding feature is enabled, we use maybenot, which does
not yet support rand 0.10. In the meantime, enabling this feature pulls
in rand 0.9. This is not ideal, but should be okay as a temporary
situation.
This also replaces the use of ReseedingRng (which was removed in 0.10)
with the reseeding_rng crate. This is somewhat less performant, but it
should be okay.
|
| |
|
|
|
|
|
|
|
| |
From the reactor.rs to channel.rs, makes more sense and we'll need it in
the handshake tests.
No behavior change, just code movement and a function rename.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
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]>
|
| |
|
|
|
|
|
|
|
|
| |
This trickles down to the tor-proto channel handshake code. But, the
real need is in the channel builder in order to validate the outbound
channel target.
Fixes #2440
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.
|
| |
|
|
| |
for handling CREATE* messages on channels.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
| |
We use this constant value when building the AUTHENTICATE cell to
optimize the memory allocation as this won't ever change.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Only get the inner generic unverified channel into a verified channel
after the actual verification in the relay responder handshake.
Some variables needed a rename as this was dangerously named.
No behavior change.
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3791#note_3374481
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
| |
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3791#note_3374462
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
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
|
| |\
| |
| |
| |
| | |
cell, proto, cert: Simplify CERTS cell building.
See merge request tpo/core/arti!3795
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Formerly we required the caller for push_cert_body to specify the
type of the cert that they were pushing. But in nearly every case,
the certificate object that the caller is holding knows what its
own type is! This makes the tor_proto build_certs_cell function
a bit less error-prone, since we don't have to worry about mismatch.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
As a responder, we should check the AUTHENTICATE auth type and make sure
we support it. We were not doing that, we were simply putting in our max
version.
Signed-off-by: David Goulet <[email protected]>
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
It is now validated against the received KP_link_ed of the initiator
peer and we compare only the section of the AUTHENTICATE cell that we
can compare (minus random bytes and sig).
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]>
|
| | |
| |
| |
| |
| |
| | |
The responder channel will soon use it.
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]>
|
| |
|
|
|
|
|
| |
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]>
|
| | |
|
| |\
| |
| |
| |
| | |
relay: Couple fixes related to channel creation
See merge request tpo/core/arti!3726
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| |/
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
|
| |
It was all commented out until now that we have a final
RelayIdentities.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
| |
These were previously in a single `Option`, but now that the `Option`
was removed, I think it's nicer to make these separate fields.
|
| |
|
|
|
|
| |
I don't think that the `Option`s are needed anymore, since
unauthenticated channels no longer transition through the
`VerifiedChannel` state.
|
| |
|
|
|
|
|
|
|
|
| |
The validate_relay_target() is meant to probably have more checks in the
future hence the vagueness of it instead of being specific to the goal
of this patch.
Closes #1699
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
| |
This commit also adds the TlsKeyAndCert to the identities so the TLS
acceptor can set it up.
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]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
| |
This type is needed in the tor-chanmgr crate in order to decide to
verify or not the underlying relay channel.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This requires the `TlsKeyAndCert` so be passed on the TLS acceptor
settings. We assume that `RelayIdentities` has this information.
The ChanBuilder::new() was getting a bit too convoluted and feature
gated to instead we introduce new_client() and new_relay() and remove
the need for `with_identities()`.
Because of this, the ChanMgr::new() now returns a `Result<>`.
Related to #1597
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
| |
No need for these types, we've replaced them with more specific types.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
Add the unverified, verified, non verifiable flavor types of a responder
channel.
This follow on the previous commit to use the type system for stronger
guarantees.
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]>
|
| |
|
|
|
|
|
|
|
| |
itself
Previous function "build_auth_data()" is still around but will be
removed in the upcoming commits.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the channel type from Unverified and Verified channels and
instead use the channel type in the underlying channel codec.
The codec requires such type in order to restrict messages sets. Instead
of duplicating it, this commit simply makes it that there is now only a
single channel type attached to a channel structure.
The resulting `struct Channel` in the end gets it copied from the
channel codec as the framed_tls gets split and given to the `Reactor`.
Down the line, we need a channel type attached to the `Channel` in order
to know if it is a client or not and authenticated or not.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|