| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This introduces verify_tls_cert() standalone function. It is such
because both client and relay initiator will use it.
For now, the check_internal() has been modified to use it. We are slowly
building towards having specialized check function per channel type.
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is a loaded commit, apologize in advance but not many way around
this.
One thing that is generic to all verifiable channel (authenticated) is
that they all need to check the relay identities and signing key from
the CERTS cell.
This commits extracts that part into
UnverifiedChannel::check_relay_identities() which returns those said
identities and the signing key (KP_relaysign_ed).
The signing key is actually needed for only one context, the initiator
part because the TLS cert is signed with it. The LINK AUTH cert is
signed by the ed25519 identity key itself which is what the responder
will look for.
This commit has two side effects which I believe are OK:
1. The timeliness check of the identity certs is now done prior to the
other cert (TLS/LINK).
2. We no longer check signatures in batch mode as we can't batch ed25519
sig check with the RSA crosscert sig. It appears the batch validation
was there for performance and not for security purposes.
The end goal of this piece of work is that the specialized channel will
start by calling a generic check function that will call
check_relay_identities(). And then, the secondary certificates will get
checked depending on the side of the channel.
Expect also a variable rename commit at the end as the naming in this
function is really bad.
Signed-off-by: David Goulet <[email protected]>
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Move two inline functions located in UnverifiedChannel::check_internal()
into the UnverifiedChannel object itself.
Laying down the ground work for the more specialized objects to use
those as the check_internal() is about to get massively refactored into
more specific channel types.
Signed-off-by: David Goulet <[email protected]>
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
tor-geoip: Update geoip manually
See merge request tpo/core/arti!3793
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit updates the geoip database manually using the infrastructure
from the Tor repository, mainly because the database has last been
refreshed about 3 years ago.
Of course we should embed this into the Arti release process, but
because the location database format is non-trivial, this might take a
bit longer to implement and in the VPN project we are currently facing
bugs that might be related to an outdated geoip database.
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
tor-netdoc: parse2: Rework signature handling
See merge request tpo/core/arti!3765
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Suggested-by: Clara Engler <[email protected]>
|
| | | |
| | |
| | |
| | |
| | | |
This is implied by `body` being the body before the first signature
item, but needs to be part of the definition.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
"Regular" is confusing, especially since in American English it tends
to mean "usual" - whereas, there are no orderly signatures in Tor
netdocs.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
I have been losing my way in this file a lot. This may help.
|
| | | |
| | |
| | |
| | |
| | | |
This could allow users to attach and detach signatures, hash (only)
the body part, etc.
|
| | | |
| | |
| | |
| | | |
Such an impl is a footgun. Explain this in docs & comments.
|
| | | |
| | |
| | |
| | | |
(pre-fmt)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We want to stop deriving NetdocParseable directly for body structs.
This test case does in fact parse a signed authcert and extract just
the body without verifying the signatures. That's fine in a test, but
we're going to make it involve some hoop-jumping. So, jump those
hoops.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We want to stop deriving NetdocParseable directly for body structs.
Doing so reveals a call site here in tor-dirmirror where a consensus
is parsed and the body data used, but without verifying the
signatures.
Do this explicitly with the hoop-jumping which is going to become
deliberately unavoidable. Add a TODO comment because I'm not sure we
have decided explicitloy that this is OK.
|
| | | |
| | |
| | |
| | | |
Formatting changes which make the next commit more readable.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Replace the two separate NetdocParseable and NetdocUnverified derives,
for toplevel signed documents, with a single derive.
This makes the derive API simpler. It will also make it reasonably
possible to avoid deriving NetdocParseable directly for body structs.
Such impls are a security hazard!
In detail:
* Rename NetdocUnverified to NetdocParseableUnverified
* Have it use $IMPL_NETDOC_PARSEABLE from the NetdocParseable deftly
module so that it derives NetdocParseable for the body.
(We'll change this later in the series.)
* Adjust the docs and all call sites.
|
| | | |
| | |
| | |
| | |
| | | |
We are going to want to reuse this parsing implementation in another
top-level deftly template.
|
| | | |
| | |
| | |
| | |
| | | |
Run rustfmt and selectively apply the hunks that are relevant to the
previous commit.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
During encoding, including these hashes in the signature items makes
no sense. The hashes are an *input* to the signature items, but not
part of them.
Move the hashes out of the items. Instead, provide each signatures
section type with a hash accumulator type, in which the hash(es) are
stored.
|
| | | |
| | |
| | |
| | |
| | | |
Nonfunctional and formatting changes which reduce noise in the next
commit.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This is going to contain body information, and the hashes, too.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This is going to be its own trait and it is usually best if macros are
named after traits, rather than having the macro derive a different
trait depending on meta attributes.
|
| | | |
| | |
| | |
| | |
| | | |
We're going to want this for cases where the hash computation
machinery didn't DTRT.
|
| | | |
| | |
| | |
| | | |
We're going to want this for sets of netdoc signature hashes.
|
| | | |
| | |
| | |
| | | |
For reuse when we split up the NetdocParseable derive.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
But, all signatures in the current protocol are irregular :-/.
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | | |
chanmgr: Add a list of unauthenticated channels
See merge request tpo/core/arti!3790
|
| | | |
| | |
| | |
| | | |
Signed-off-by: David Goulet <[email protected]>
|
| | | |
| | |
| | |
| | | |
Signed-off-by: David Goulet <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Put channel without relay identities in the unauth_channels list.
Signed-off-by: David Goulet <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Needed to handle client/bridge -> relay channels which are not
authenticated meaning they don't have a RelayIds so they can't be put in
the ListByRelayIds<>.
Feature gate it to "relay" as a client will never have those kind of
channels.
Signed-off-by: David Goulet <[email protected]>
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
arti-extra build: enable everything in full and experimental
See merge request tpo/core/arti!3759
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Including these would introduce flakiness, until arti#2400 is resolved.
This also adds a general mechanism for omitting specific features in the
arti-extra build.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously we enabled features piecemeal to avoid enabling `rpc`, which
resulted in breakage when running under shadow. Experimentally, this
appears to no longer be the case.
Enabling everything in `full` and `experimental` gives us at least a
little bit of testing of those features (that they don't break the build
or other usage), even if we don't specifically exercise them (yet) in
the CI tests.
|