| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes:
```text
$ cargo test -p tor-proto --features relay
error[E0603]: enum import `CtrlMsg` is private
--> crates/tor-proto/src/relay/reactor.rs:463:33
|
463 | use crate::channel::CtrlMsg;
| ^^^^^^^ private enum import
|
note: the enum import `CtrlMsg` is defined here...
--> crates/tor-proto/src/channel.rs:117:5
|
117 | use testing_exports::*;
| ^^^^^^^^^^^^^^^^^^
note: ...and refers to the enum import `CtrlMsg` which is defined here...
<snip>
```
There are a few ways we could fix this, but I don't see an advantage of
one over another.
|
| |
|
|
|
|
| |
The relay circuit reactor tests will soon need the ability to send
control messages (for allocating a circuit id for the circuit reactor
under test).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A CircId is now a circ_id and a UniqId is a unique_id so we stop
confusing them in the code.
Furthermore, channel_id that are CircId are now circ_id. Channel IDs are
different and encoded internally into a UniqId.
This is the first step to clarify semantic before we change the logging
to log both unique ID and circ ID.
No behavior change.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
These help to establish connected channel objects to be used for tests.
|
| |
|
|
|
|
|
|
|
|
| |
This is needed for relays as part of #2490.
Note that changing this type affects the client implementation too (i.e.
clients will start prioritizing inbound DESTROY, discarding any queued
data without forwarding it to their local streams). But that's okay,
because it will generally only affect misbehaving clients, and clients
unlucky enough to encounter a hibernating relay.
|
| |
|
|
|
|
| |
To avoid copying the same information for every circuit,
as suggested by @opara in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3906#note_3399497
|
| |
|
|
| |
This is used in the relay circuit reactor.
|
| | |
|
| |
|
|
| |
This will be needed for ntor handshakes.
|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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]>
|
| |\
| |
| |
| |
| | |
Add support for handling CREATE_FAST cells and launching a circuit reactor
See merge request tpo/core/arti!3846
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| | |
When used for relay channels, the channel reactor will soon need to
spawn relay circuit reactors.
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
memquota: Add new add_parent() API
Closes #2427
See merge request tpo/core/arti!3829
|
| | |
| |
| |
| | |
Closes #2427
|
| |/
|
|
|
|
| |
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3791#note_3374457
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| |
|
|
|
| |
This was previously creating a new CircuitAccount in
`new_outbound_circ()`, and then immediately dropping it.
|
| | |
|
| |
|
|
|
|
| |
Rename them to respectively sensitive() and not_sensitive().
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]>
|
| |
|
|
|
|
| |
Closes #1601
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]>
|
| |
|
|
|
|
|
| |
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]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
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 struct will be put in a Channel and derived from the received
NETINFO cell.
This follows the C-tor implementation for which we have two indicator of
canonicity:
1. Peer is canonical: the address they advertise in the NETINFO cell
matches the one we see on the TCP connection.
2. Canonical to peer: the peer sees us as canonical.
Those flag will get used to select "the best" channel.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
This is currently very similar to its client counterpart.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
| |
This will be used in the stream reactor too (and the stream reactor will
eventually replace the corresponding client impl).
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is so check() only authenticate a channel. The finish() function
now only sends back the missing cells and build the final Channel.
To pull this off, the AUTHENTICATE cell and our IP addresses need to be
copied into the VerifiedRelayChannel.
This allows us to remove complexity into the check() function as well
and future commit will remove the async.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit is a bit loaded but it is coherent.
First, we set Eq and PartialEq to the channel message Authenticate so we
can compare it with the one we expected.
Second, the AuthenticationCell enum is introduced to store either an
AUTH_CHALLENGE or an AUTHENTICATE since one side of the handshake can
only have one. This allows us to store one or the other in
UnverifiedRelayChannel.
Depending on what we have, the authentication process is different as it
dictates which side we are on (initiator vs responder). Keep in mind
that the handshake code enforces receiving a AUTH_CHALLENGE along side
CERTS. And same goes for AUTHENTICATE which means that if we have an
AUTH_CHALLENGE in the UnverifiedRelayChannel, it is certain that the
other side wants to authenticate and we are the initiator.
Finally, the sending of CERTS and AUTHENTICATE by the initiator is now
in UnverifiedRelayChannel::check() done right after verifying the
channel CERTS and holding a "VerifiedChannel" object.
This means that the last piece, sending the `NETINFO` by the initiator
will be done in the check() but in a future commit. This leaves the
VerifiableChannel::finish() to send nothing and only finalize the
channel with the NETINFO (canonicity).
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
Relay initiator needs to send CERTS and AUTHENTICATE in that function
after verifiying the channel.
And thus require to be async.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This requires to make a series of cert and digest also optionnable in
the VerifiedChannel.
This change is needed because as a relay responder, you might get the
CERTS or not depending on if the other side wants to authenticate.
Client and bridges do not authenticate and thus it is expected to not
have a CERTS cell.
This leads to the UnverifiedChannel::check() function to return early
with a VerifiedChannel without any identity attached to it.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| |
|
|
|
|
| |
They are public but avoid anyone outside implementing them.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|