| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
The UnverifiedChannel::finish() was split in previous commit so this
adds the support for sending the right NETINFO cell instead of the
client specific one.
Added more TODOs for followup commits.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
| |
Add the finish() function that for now simply calls the generic
finish(). There is a bunch of TODO in the code in this commit explaining
why we haven't made the implementation relay specific just yet.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commits takes out the relay specific code out of UnverifiedChannel
and puts it in UnverifiedRelayChannel.
In order to pull this off, we added some fiels to the VerifiedChannel
struct so the relay code get back generated data from the
UnverifiedChannel::check() in order to do its validation work and yield
a VerifiedRelayChannel.
This also lead to a cleanup of expect() and ChannelType::is_initiator().
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
The new UnverifiedRelayChannel and VerifiedRelayChannel struct are added
to decouple the client code and put the relay component in its module.
Both objects hold the to become generic object that both client and
relay will use to create a channel.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
We don't really need this channel here, because we already have control
and command channels for checking if the reactor task is still alive.
|
| |
|
|
|
|
|
|
|
| |
While this is technically a "reactor handle", I think RelayCirc sounds
better, because this is essentially our only public API for interacting
with a relay circuit (it will be used outside of tor-proto).
(This would also be consistent with our existing ClientCirc
client-side terminology).
|
| |
|
|
| |
This will soon become `pub`, so I am factoring it out of `reactor.rs`.
|
| |
|
|
|
|
|
|
| |
BackwardReactor is an implementation detail, so it shouldn't really be
mentioned in the soon-to-be-public-facing docs.
And besides, the control messages are no longer handled by the
BackwardReactor.
|
| |
|
|
| |
We replaced TunnelId with UniqId in the relay code a while ago.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is only done if we kept the AUTH_CHALLENGE cell and we have relay
identities. In other words, this is only when the UnverifiedChannel was
created from a RelayInitiatorHandshake.
Note: The check_internal() function is too large and should be
refactored in smaller pieces.
Note: It is also likely that we need to split UnverifiedChannel and
VerifiedChannel as it is getting client or relay members. Not great.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
The client and relay channel builder don't share anything and return
different objects hence the seperation.
Furthermore, this seperation avoids having the client ChanMgr ability to
launch relay channels.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a intermediary object between tor-chanmgr and tor-proto that is
when building a relay channel, those keys/certs need to be set in the
ChannelBuilder so the tor-proto can use them to authenticate.
We avoid that way making tor-proto depending on tor-keymgr for the
ultimate goal to avoid tor-proto to have access to all the keys in the
KeyMgr.
Future commits will introduce a relay channel builder which will use
that object to set the keys.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
This commit only adds a struct holding all the authentication data that
needs to be built during the verification process after all handshake
cells needed for authentication have been sent.
It lives in the VerifiedChannel struct so it can be used to build the
AUTHENTICATE cell and be sent before the NETINFO.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
| |
This implements the relay initiator side of the handshake up to the
creation of an unverified channel.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
We need to give the control channels higher priority here.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Control messages are handled in RelayReactor instead of BackwardReactor.
|
| |
|
|
|
| |
This only moves the control/command fields to RelayReactor. The next
step is to actually implement the control message handling and dispatch.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The `RelayReactor` now holds the sending end of the shutdown broadcast
channel, so if `RelayReactor` exits, both the forward and the backward
relay reactor will notice and shut down too.
Similarly, if the forward or backward reactor exits, the `RelayReactor`
will notice (because it select!s between the two), and will shut down
|
| | |
|
| |
|
|
|
| |
I used `futures::join` by mistake: the intention here is to have
`RelayReactor` exit when either one of the fwd/bwd reactors exits.
|
| | |
|
| | |
|
| |
|
|
| |
This also clarifies why we reroute cells to `BackwardReactor`.
|
| |
|
|
|
| |
Things will get very confusing if every reactor uses different variable
names for this, so I am renaming it back to input.
|
| |
|
|
|
|
|
|
| |
The channel provider is used to request outgoing channels from the
`ChanMgr` in response to `EXTEND`/`EXTEND2` cells, so it belongs in the
`ForwardReactor`.
(This was leftover from the old circ reactor architecture)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This is the first step towards parallelizing stream reads and
writes.
|
| |
|
|
|
| |
This makes it a bit clearer that `cell_rx` is for moving stream data
between `ForwardReactor` and `BackwardReactor`.
|
