| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
| |
This tests that the client configured in the `authorized_clients`
directory of the service is able to connect.
|
| |
|
|
|
| |
This will be used with the new `fileserver-onion-arti-auth` test hidden
service.
|
| |
|
|
|
|
|
|
|
| |
This adds a new restricted discovery hidden service
(`fpqqmiwzqiv63jczrshh4qcmlxw6gujcai3arobq23wikt7hk7ojadid.onion`)
that has 2 authorized clients:
* `alice`, the client configured in the `restricted_discovery.static`
list in its TOML config
* `default`, the client configured in `authorized_clients/default.auth`
|
| |
|
|
|
|
|
| |
This adds an onion service that uses full vanguards, and a client
that connects to it.
Closes #1408
|
| |
|
|
| |
Closes #1283
|
| |
|
|
|
|
|
|
|
|
|
| |
The onion service keys now live in the `hss/<nickname>` subdirectory
within the keystore.
This layout change is **not** backwards-compatible, so if you want to
use your existing hidden service keys, you will need to manually move
them to `<keystore_root>/hss`.
Closes #1260
|
| |
|
|
|
|
|
| |
The role is a slug, and slugs are not allowed to contain uppercase
characters.
Closes #1195
|
| |
|
|
|
|
| |
We are about to replace `ArtiPathComponent` with `Slug`, but `Slug`s
don't support `.`, so let's strip the `.onion` suffix before encoding it
in the `ArtiPath`.
|
| |
|
|
|
| |
The algorithm name for x25519 keys has changed, so the test keys need to
be updated.
|
| |
|
|
|
| |
The algorithm name for expanded ed25519 keys has changed, so the test
keys need to be updated.
|
| | |
|
| |
|
|
|
| |
This also adds a workaround - the arti service doesn't appear to
register itself (set up intro points) unless first used as a client.
|
| |
|
|
| |
This is to ensure a stable HS address.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The arti-extra binary has several experimental features enabled.
Currently it is used to test experimental onion service features, but it
would be useful also do a test of the arti-extra binary in the same
configuration and workload as the arti binary (which has the default
featureset).
In a follow-up commit, we'll enable the experimental ntor-v3 handshake
implementation in the arti-extra binary.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are 2 reasons to make this change:
* because having the word `private` in the extension will make it more
difficult to accidentally misuse or misplace a private key (see
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1618#note_2947461)
* because `Keystore`s will soon grow a `list()` function returning all
`(ArtiPath, KeyType)`s in the keystore, and in order for
`ArtiNativeKeystore` to implement this function, it will need to be
able to reverse the `KeyType -> file extension` mapping (if two
different `KeyType`s are mapped to the same extension,
`ArtiNativeKeystore`s won't be able to reverse the mapping)
|
| |
|
|
| |
The secret keys are prefixed with `KS`, not `KP`.
|
| |
|
|
| |
The privateness of the keys is encoded in their name.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the Arti key store would store x25519 secret keys as ed25519
OpenSSH keys, which it would convert to x25519 upon loading (using the
conversion function added in !1297 (merged)). This approach isn't good
enough though: most people will probably want to bring their existing
x25519 keys, and in order to store those in OpenSSH format, we'd need
convert them to ed25519, which is impossible (because the secret part of
an x25519 key contains a SHA512'd secret, whereas the corresponding,
"un-expanded", ed25519 secret key contains the secret itself rather than
the SHA).
Now that `ssh-key` has support for ssh keys with [custom algorithm
names], we can store x25519 in OpenSSH format directly. This commit
changes the storage format used by the keymgr for x25519 client auth
keys (from ed25519-ssh to our own custom key type with an algorithm name
of `"[email protected]"`).
Closes #936
[custom algorithm names]: https://github.com/RustCrypto/SSH/pull/136
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Without this, the onion client was failing to find a guard.
We recently made this change in shadow's "tor minimal" test as well.
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
Fixes https://gitlab.torproject.org/tpo/core/arti/-/issues/174
|