We will use this for a lack of HS directories. (These aren't chosen
according to any local restrictions, so the problems with EK::NoPath
and EK::NoExit don't arise.)
Fixes
cargo +stable test --locked --offline F -p tor-netdoc
cargo +stable clippy -p tor-netdoc F --all-targets
for values of F including
--all-features
--features=hs-client
--features=hs-common
--features=hs-service
(nothing)
I couldn't find a test vector in C Tor. This test case was generated
from the code here.
I'm fairly sure it's right since I managed to get my descriptor
downloader to work. (That's not an MR yet, but uses this code.)
So far these are just the errors that occur during descriptor
fetch. There will be more later as we have more code in tor-hsconn.
This is very user-facing; use the "onion service" terminology.
Previously, to build descriptors for hidden services with client auth
enabled, in addition to the list of authorized clients, users of
`HsDescBuilder` were required to also provide a descriptor encryption
keypair and a descriptor cookie. This was potentially dangerous and/or
error-prone, because the ephemeral encryption key and the descriptor
cookie are expected to be randomly generated and unique for each
descriptor.
This change makes `ClientAuth` private to the `hsdesc::build` module and
updates `HsDescBuilder` to build `ClientAuth`s internally. Users now
only need to provide the list of authorized client public keys.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
This adds a test for an `encode -> decode -> encode` flow for a hidden
service descriptor with client authorization enabled.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
`AuthClient`s were originally meant to represent parsed `auth-client`
lines. In !1070, this struct was repurposed for representing individual
authorized clients in the HS descriptor encoder. However, hidden
services will likely use a list of public keys to represent the
authorized clients rather than a list of `AuthClient`s, as the
information from an `AuthClient` (`client_id`, `iv`, `encrypted_cookie`)
likely won't be immediately available to the hidden service.
This change updates the HS descriptor encoder to represent authorized
clients as a list of `curve25519::PublicKey`s. As such, it is now the
responsibility of the encoder to create the `client_id`, `iv`, and
`encrypted_cookie` using the available keys, the unencrypted descriptor
cookie, and HS subcredential.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
These crates had no changes until just a moment ago. But since
we updated the versions on some of their dependents, they have now
changed themselves. Thus they get patchlevel bumps.
```
tor-rtmock
tor-protover
tor-socksproto
tor-consdiff
tor-chanmgr
tor-dirclient
tor-hsservice
```
For these crates, the changes are nontrivial, so we
_do_ bump the versions on which their dependent crates depend.
Fortunately, since they are all pre-1.0, we don't need to
distinguish semver-additions from other changes. (Except for arti,
which _is_ post-1.0, but gets a patchlevel bump anyway.)
These are unstable crates with breaking changes:
```
tor-hscrypto
tor-hsclient
```
These have new or extended APIs:
```
safelog
tor-bytes
tor-cell
tor-linkspec
tor-llcrypto
tor-proto
tor-cert
arti-client
```
These have new unstable APIs or features:
```
tor-netdoc
tor-circmgr (also broke some unstable APIs)
arti (is post-1.0)
```
These have bugfixes only:
```
caret
tor-dirmgr
```
Their dependents are _not_ updated to a more recent version.
These bumped the version of a dependency that they don't expose
```
tor-rtcompat
fs-mistrust
```
This one had internal refactoring:
```
tor-netdir
```
These had trivial changes only:
```
tor-checkable
tor-ptmgr
tor-guardmgr
arti-hyper
arti-bench
arti-testing
```
I found that I had the bug where I forgot to call this function, and
reached
bad_api_usage!("The circuit launcher wasn't initialized")
The possibility of such a bug is a hazard of this API pattern.
I don't think the server-side support will want to explicitly call
current and then secondary. Rather, it will want to iterate over all
the relevant ones.
And fix the name, and add another comment about whether we need this.
Change its name to hs_* like we do with things at this layer.
But, it turns out, that at least for hs client connections to fetch
the descriptor, I don't seem to need to call it yet ? Maybe it's not
needed.
* Don't ever use the words "parameter" or "param".
These doesn't appear in the spec anywhere.
* Use `h` as the variable name for the unclamped blinding factor,
and `blinding_factor` in function names.
Unhelpfully, the spec uses the variable name `h` and the phrase
"blinding factor" for both the unclamped and clamped value. The
clamped value is internal to the algorithm.
In our code:
* Don't ever use the word "parameter" or variable name `param`.
This doesn't appear in the spec anywhere.
* Use `h` for the unclamped blinding factor, and `blinding_factor` for the
clamped blinding factor.
* Rename `blinding_factor` function to `clamp_blinding_factor`, since
in the spec's terminology it takes an (unclamped) "blinding factor"
and returns a (clamped) "blinding factor".
* State explicitly what thing in the spec the `h` parameters are.
There are too many things called "index" here. `idx` could be read to
mean the table index `RouterStatusIdx`, the hsdir hash `HsDirIndex`,
or an entry in some other one of these tables.
Here's, it's just the sequence number of the index in the test netdir.
Use `pos` for that. (`seq` would have been another possibility.)
The hidden services directory hashring is a ring of hsdir relays,
sorted by a hash that the spec calls the "index". That's `HsDirIndex`.
This was a bad idea because the word "index" is seriously overused,
but in Arti we must use the same terminology.
At least, qualify it everywhere. Now one of these hsdir sort position
hashes is always, in our code, an `hsdir_index`.
I think this is necessary even inside modules called `hsdir_*`,
because those can deal with other kind of "index" too.
This is an `IndexVec` key type. Some places used `idx`, some `rsi`,
some `rs_idx`.
Use `rsidx` for it everywhere, including in locals, function names,
and fields. `rsidx` is a compromise. `rsi` might be a bit opaque,
but we want a one-"word" name since it appears inside other names.
This fixes a broken doc link I introduced in !1070:
```
error: unresolved link to `crate::doc::hsdesc::build::inner::HsDescInnerBuilder`
--> crates/tor-netdoc/src/doc/hsdesc/build/middle.rs:34:11
|
34 | /// [`crate::doc::hsdesc::build::inner::HsDescInnerBuilder`] as described in sections
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no item named `HsDescInnerBuilder` in module `inner`
|
= note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings`
error: could not document `tor-netdoc`
```
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
Hidden services use blinded singing keys derived from the identity key
to sign descriptor signing keys.
Before this patch, the hidden descriptor builder represented its blinded
signing keys (`blinded_id`) as plain `ed25519::Keypair`s. This was not
ideal, as there was nothing preventing the caller from accidentally
initializing `blinded_id` with an unblinded keypair.
This introduces a new `HsBlindKeypair` type to represent blinded
keypairs.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
`NetdocText` is a wrapper around a `String` and a type marker. The type
annotation proved of limited use, and made the netdoc builder API
somewhat awkward to use.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
Unlike `hsdesc::IntroPointDesc`, `hsdesc::build::IntroPointDesc`
represents link specifiers as `LinkSpec`s rather than
`UnparsedLinkSpec`s.
Since this is a general-purpose representation of an introduction point
and not merely an intermediate representation for decoding/encoding, it
will probably need to be factored out of `tor-netdoc` at some point.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
This introduces the `NetdocBuilder` trait described in
`netdoc-builder.md` and a new `tor-netdoc::doc::hsdesc::build` module,
which exports the `HsDescBuilder`. Hidden services will use
`HsDescBuilder` to build and encode hidden service descriptors.
There are several TODOs in the code that I'm planning to address
separately.
Partially addresses #745.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
These are used in multiple places (and will also be used by the HS
descriptor encoder later on), so let's make them named constants.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
This makes some code a bit more concise, as it allows us to make
`Strings` into `ItemArgument`s without calling `.as_str()`.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
We're going to want to reuse this.
Also: rename StreamPrefs::isolation and update the docs, to better
reflect its rather limited functionality. The new
TorClient::isolation is the only call site.
We now have support for a pool of pre-build circuits that we can use
for HS-related purposes, and we take circuits from this pool as
needed.
Nothing populates or cleans the circuit pool yet.
Since we made the internals of the ptmgr protocol parser
conditionally private, we need to tell Cargo to build the fuzzer
with the `experimental-api` feature so that it can access them.
Nick Mathewson
Ian Jackson
Ian Jackson
gabi-250
Alexander Færøy
eta
Gabi Moldovan
Dimitris Apostolou
trinity-1686a