summaryrefslogtreecommitdiff
path: root/crates
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | retry-error: Fix typo in dedup_by descriptionTobias Stoeckmann2026-03-171-1/+1
| | | | | | | | | | | | | | | | The function argument is named same_err, not dedup.
* | | | proto: Compare AUTHENTICATE expected body in constant-timeDavid Goulet2026-03-191-1/+3
| | | | | | | | | | | | | | | | Signed-off-by: David Goulet <[email protected]>
* | | | proto: The relay signing key signs the auth certDavid Goulet2026-03-192-9/+6
| | | | | | | | | | | | | | | | | | | | | | | | In other words kp_relaysign_ed. Signed-off-by: David Goulet <[email protected]>
* | | | proto: Check the AUTHENTICATE auth type that we support itDavid Goulet2026-03-194-1/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* | | | chanmgr: Don't build relay channel if method is not DirectDavid Goulet2026-03-191-0/+6
| | | | | | | | | | | | | | | | Signed-off-by: David Goulet <[email protected]>
* | | | chanmgr: Clarify the use of no identity ChanTargetDavid Goulet2026-03-192-9/+14
| | | | | | | | | | | | | | | | Signed-off-by: David Goulet <[email protected]>
* | | | cell: Use Error::MissingData if Authenticate fields length is wrongDavid Goulet2026-03-191-26/+16
| | | | | | | | | | | | | | | | | | | | | | | | Proper error to use and better code to use checked_sub(). Signed-off-by: David Goulet <[email protected]>
* | | | tor-proto: fix the relay responder's CLOG/SLOG digestsSteven Engler2026-03-192-20/+37
| | | |
* | | | tor-proto: fix the relay initiator's SLOG digestSteven Engler2026-03-194-13/+47
| | | |
* | | | tor-proto: get SLOG/CLOG outside of `ChannelAuthenticationData`Steven Engler2026-03-193-10/+24
| | | |
* | | | tor-proto: improve chan send/recv-log error messagesSteven Engler2026-03-191-2/+6
| | | |
* | | | tor-proto: build AUTHENTICATE after sending CERTSSteven Engler2026-03-191-15/+22
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | cell: Simplify the Authenticate APIDavid Goulet2026-03-192-21/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the is_equal_no_sig() and instead add a getter that returns a reference to the body without the random part so it can be used to verify the signature. The caller now checks the equality with what it is expected. Signed-off-by: David Goulet <[email protected]>
* | | | proto: Fix AUTHENTICATE equality check and signature checkDavid Goulet2026-03-192-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes two things. 1. The "is_equal_no_sig()", if true, was going into the error path. 2. The signature verification is done against the body of the AUTHENTICATE cell that is all fields except the signature. Next commit will change the is_equal_no_sig() to make more sense with the "body" semantic. Signed-off-by: David Goulet <[email protected]>
* | | | proto: Set the link protocol outside the recv VERSIONS helperDavid Goulet2026-03-193-17/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It used to work for an initiator to set the link protocol once a VERSIONS is received because initiator send their VERSIONS before. This failed with responders because a responder channel sends their VERSIONS after receiving one from the initiator. This reverse logic means that the channel cell handler was transitionned to the Handshake state before a responder was able to send a VERSIONS cell leading to a failure because VERSIONS cell aren't allowed at the Handshake state. To fix this, the send/recv or recv/send is now explicit per channel type and once this is done and successful, the link protocol is set. A `set_link_protocol()` is added to the ChannelBaseHandshake trait so it can be used to set the cell handler. Signed-off-by: David Goulet <[email protected]>
* | | | proto: Fix unit testsDavid Goulet2026-03-191-7/+17
| | | | | | | | | | | | | | | | Signed-off-by: David Goulet <[email protected]>
* | | | proto: Improve logging in channel handshakeDavid Goulet2026-03-191-2/+2
| | | | | | | | | | | | | | | | Signed-off-by: David Goulet <[email protected]>
* | | | chanmgr: Don't get the peer cert as a responder channelDavid Goulet2026-03-191-9/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No initiator present a TLS certificate and so don't try to get one. Fixes #2388 Signed-off-by: David Goulet <[email protected]>
* | | | proto: Responder channel properly validates the AUTHENTICATE cellDavid Goulet2026-03-193-18/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* | | | proto: Add specialized build functions for ChannelAuthenticationDataDavid Goulet2026-03-194-67/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* | | | proto: New UnverifiedInitiatorChannelDavid Goulet2026-03-195-174/+146
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* | | | proto: Move cert validation per specialized channelDavid Goulet2026-03-195-94/+153
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* | | | proto: Add the verify_link_auth_cert() helperDavid Goulet2026-03-192-2/+58
| | | | | | | | | | | | | | | | | | | | | | | | The responder channel will soon use it. Signed-off-by: David Goulet <[email protected]>
* | | | proto: Use RelayIds in a VerifiedChannelDavid Goulet2026-03-195-64/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* | | | proto: Move into a helper function the TLS cert validationDavid Goulet2026-03-191-28/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* | | | proto: Split relay identity checks from CERTS into its own functionDavid Goulet2026-03-191-90/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* | | | proto: Extract inline helpers into struct itselfDavid Goulet2026-03-191-40/+46
| |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* | | Merge branch 'update-geoip' into 'main'Alexander Hansen Færøy2026-03-192-66298/+422637
|\ \ \ | | | | | | | | | | | | | | | | tor-geoip: Update geoip manually See merge request tpo/core/arti!3793
| * | | tor-geoip: Update geoip manuallyClara Engler2026-03-192-66298/+422637
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: signature orderliness: add some xrefsIan Jackson2026-03-192-1/+6
| | |
* | | tor-netdoc: signature ordering: discuss an alternative impl approachIan Jackson2026-03-191-0/+3
| | | | | | | | | | | | Suggested-by: Clara Engler <[email protected]>
* | | tor-netdoc: signature orderliness: orderly signs don't cover other sigsIan Jackson2026-03-191-0/+1
| | | | | | | | | | | | | | | This is implied by `body` being the body before the first signature item, but needs to be part of the definition.
* | | tor-netdoc: signature orderliness: shuffle wording slightlyIan Jackson2026-03-191-1/+1
| | |
* | | tor-netdoc: signature orderliness: change terminologyIan Jackson2026-03-192-8/+8
| | | | | | | | | | | | | | | | | | "Regular" is confusing, especially since in American English it tends to mean "usual" - whereas, there are no orderly signatures in Tor netdocs.
* | | tor-netdoc: NetdocParseableSignatures: discuss orderingIan Jackson2026-03-191-0/+44
| | |
* | | tor-netdoc: Apply deferred rustfmt churn to importsIan Jackson2026-03-193-7/+7
| | |
* | | tor-netdoc: encoding: Plan for encoding signed documentsIan Jackson2026-03-191-0/+23
| | |
* | | tor-netdoc: parse2: Add some navigational commentsIan Jackson2026-03-191-1/+64
| | | | | | | | | | | | I have been losing my way in this file a lot. This may help.
* | | tor-netdoc: parse2: Include body length in SignaturesDataIan Jackson2026-03-192-0/+5
| | | | | | | | | | | | | | | This could allow users to attach and detach signatures, hash (only) the body part, etc.
* | | tor-netdoc: parse2: Don't impl NetdocParseable for bodies of signed docsIan Jackson2026-03-196-16/+105
| | | | | | | | | | | | Such an impl is a footgun. Explain this in docs & comments.
* | | tor-netdoc: parse2: Don't impl NetdocParseable for bodies of signed docs ↵Ian Jackson2026-03-192-4/+11
| | | | | | | | | | | | (pre-fmt)
* | | tor-netdoc: authcert test: Avoid using NetdocParseable for AuthCertIan Jackson2026-03-191-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | tor-dirserver: Avoid using NetdocParseable for consensusesIan Jackson2026-03-191-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | tor-dirserver: Avoid using NetdocParseable for consensuses (prep)Ian Jackson2026-03-191-4/+10
| | | | | | | | | | | | Formatting changes which make the next commit more readable.
* | | tor-netdoc: parse2: Unify top-level derive as NetdocUParseablenverifiedIan Jackson2026-03-195-37/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | tor-netdoc: parse2: Break out IMPL_NETDOC_PARSEABLE in a deftly moduleIan Jackson2026-03-191-161/+175
| | | | | | | | | | | | | | | We are going to want to reuse this parsing implementation in another top-level deftly template.
* | | tor-netdoc: parse2: Move hash out of signature items (fmt)Ian Jackson2026-03-191-17/+19
| | | | | | | | | | | | | | | Run rustfmt and selectively apply the hunks that are relevant to the previous commit.
* | | tor-netdoc: parse2: Move hash out of signature itemsIan Jackson2026-03-1912-84/+264
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | tor-netdoc: parse2: Move hash out of signature items (prep)Ian Jackson2026-03-193-13/+22
| | | | | | | | | | | | | | | Nonfunctional and formatting changes which reduce noise in the next commit.
* | | tor-netdoc: parse2: SignatureHashInputs: Include document so farIan Jackson2026-03-192-0/+5
| | |
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 12:26:41 +0000