Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:28:37Zhttps://gitlab.torproject.org/legacy/trac/-/issues/26927Improve the log message when peer id authentication fails2020-06-13T15:28:37ZteorImprove the log message when peer id authentication failsSplit off #26924.Split off #26924.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/26925Make link specifier handling in rend-spec-v3 more precise2020-06-13T15:28:36ZteorMake link specifier handling in rend-spec-v3 more preciseSplit off #26627.
We should specify that clients and services must not check untrusted link specifiers against the consensus:
https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1338
https://gitweb.torproject.org/torspec.gi...Split off #26627.
We should specify that clients and services must not check untrusted link specifiers against the consensus:
https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1338
https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705
Services should also copy unrecognized rend point link specifiers from the introduce cell to the rendezvous join cell.
We can copy the text from the service intro->rend spec:
https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705
To the the client desc->intro spec:
https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1338
Thanks to catalyst for picking up on these missing parts of the spec.
Edit: fix line numbersTor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/26924Make single onion service to rend and Tor2web to intro link authentication in...2020-06-13T15:28:35ZteorMake single onion service to rend and Tor2web to intro link authentication into a protocol warningSingle onion services and Tor2web connect directly to relays using untrusted link authentication keys.
These connections can cause a lot of warnings, particularly due to the link auth bugs in #26627.
We can either:
* downgrade all link...Single onion services and Tor2web connect directly to relays using untrusted link authentication keys.
These connections can cause a lot of warnings, particularly due to the link auth bugs in #26627.
We can either:
* downgrade all link auth warnings to protocol warnings on single onion services and Tor2web (this is the fast fix)
* taint untrusted link auth keys, and then downgrade connections using tainted keys to protocol warnings (this is very intrusive)Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/26627HSv3 throws many "Tried connecting to router at [IP:port], but RSA identity k...2020-06-13T15:28:36ZGeorge KadianakisHSv3 throws many "Tried connecting to router at [IP:port], but RSA identity key was not as expected"A popular-ish HSv3 operator contacted me and told me that they've been getting lots of warnings on their logs:
```
[warn] Tried connecting to router at [IP:port], but RSA identity key was not as expected: wanted [hex string] + [base64 s...A popular-ish HSv3 operator contacted me and told me that they've been getting lots of warnings on their logs:
```
[warn] Tried connecting to router at [IP:port], but RSA identity key was not as expected: wanted [hex string] + [base64 string] but got [same hex string] + no ed25519 key.
```
They are afraid it's some sort of downgrade attack. We should look into this.Tor: 0.3.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/24103Remove the NoEdConsensus flag2020-06-13T15:16:43ZteorRemove the NoEdConsensus flagWhen we have ed keys in the consensus, we won't need this flag any more.
And so we won't need to write any code to actually use it in relays or clients.When we have ed keys in the consensus, we won't need this flag any more.
And so we won't need to write any code to actually use it in relays or clients.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23886Write FFI bindings and function pointers for ed25519-dalek2020-06-13T15:25:42ZIsis LovecruftWrite FFI bindings and function pointers for ed25519-dalekAs part of our efforts to get a few modules in Tor written in Rust for 0.3.3, an exceptionally easy candidate is our ed25519 code, given that the current code is already highly modularised, taking function pointers to implement an interf...As part of our efforts to get a few modules in Tor written in Rust for 0.3.3, an exceptionally easy candidate is our ed25519 code, given that the current code is already highly modularised, taking function pointers to implement an interface. I wrote [ed25519-dalek](https://github.com/isislovecruft/ed25519-dalek), and I recently revised the API to be a very close match to what tor expects, so I believe this task should be extremely easy, and a prime candidate for someone newer to Rust who wishes to learn about writing FFI. (I'm happy to pair program on this too! Also on anything else, but this too.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23170Include ed25519 relay id keys in the consensus2020-06-13T15:18:03ZGeorge KadianakisInclude ed25519 relay id keys in the consensusProposal 220 specifies how ed25519 id keys should be encoded in the consensus, but the change has not been implemented yet.
This is a problem in the next gen HS design, since prop224 specifies that the HSDir hash ring should be formed u...Proposal 220 specifies how ed25519 id keys should be encoded in the consensus, but the change has not been implemented yet.
This is a problem in the next gen HS design, since prop224 specifies that the HSDir hash ring should be formed using the relay ed25519 keys, but these are not in the consensus which means that the service and the clients need to fetch all the microdescriptors before getting an accurate picture of the hash ring. Uploading or fetching HS descriptors without having all the relay microdescriptors can lead to hash ring desynch and reachability failures.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22895Unused variables in donna's SSE2 header2020-06-13T15:11:35ZcypherpunksUnused variables in donna's SSE2 headerFWICT this only occurs on 32-bit x86 systems because of the [portability header](https://gitweb.torproject.org/tor.git/tree/src/ext/ed25519/donna/ed25519-donna-portable.h?id=3aba8490ba590899b6c23071ef0b4269d8c36d37#n147).FWICT this only occurs on 32-bit x86 systems because of the [portability header](https://gitweb.torproject.org/tor.git/tree/src/ext/ed25519/donna/ed25519-donna-portable.h?id=3aba8490ba590899b6c23071ef0b4269d8c36d37#n147).Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22460Link handshake trouble: certificates and keys can get out of sync2020-06-13T15:09:51ZteorLink handshake trouble: certificates and keys can get out of syncI'm running a recent tor master as an authority in a tor testing network:
```
[notice] Tor 0.3.1.0-alpha-dev (git-0266c4ac819d9c83) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2k, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
...I'm running a recent tor master as an authority in a tor testing network:
```
[notice] Tor 0.3.1.0-alpha-dev (git-0266c4ac819d9c83) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2k, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
```
I get this warning every so often:
```
[warn] Received a bad CERTS cell: Link certificate does not match TLS certificate
```
Is this expected?Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22052Synchronize prop224 spec with implementation2020-06-13T15:08:10ZGeorge KadianakisSynchronize prop224 spec with implementationIn our ed25519 key blinding code we have a few pieces that are not in the spec. At the very least we have the following constant strings that get hashed, which are not mentioned in the spec:
```
const char str[] = "Derive temporary sig...In our ed25519 key blinding code we have a few pieces that are not in the spec. At the very least we have the following constant strings that get hashed, which are not mentioned in the spec:
```
const char str[] = "Derive temporary signing key";
...
const char str[] = "Derive temporary signing key hash input";
```
We should eye the implementation for any other unspecified parts, and bake them in the spec.Tor: 0.3.1.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/22006prop224: Validate ed25519 pubkeys to remove torsion component2020-06-13T15:12:02ZGeorge Kadianakisprop224: Validate ed25519 pubkeys to remove torsion componentWe should validate ed25519 pubkeys used in prop224 (like the blinded key) to make sure there is no torsion components. In the case of the onion address ed25519, this ensures that there are no equivalent onion addresses due to the torsion...We should validate ed25519 pubkeys used in prop224 (like the blinded key) to make sure there is no torsion components. In the case of the onion address ed25519, this ensures that there are no equivalent onion addresses due to the torsion component.
Please see:
https://lists.torproject.org/pipermail/tor-dev/2017-April/012164.html
https://lists.torproject.org/pipermail/tor-dev/2017-April/012213.htmlTor: 0.3.2.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/20827Record guards' ed25519 identities2020-06-13T15:03:45ZNick MathewsonRecord guards' ed25519 identitiesTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19560running tor trying to access its ed25519_signing_secret_key, log message too ...2020-06-13T14:59:14Zweasel (Peter Palfrader)running tor trying to access its ed25519_signing_secret_key, log message too loudI keep my key files away from the running tor instance.
For some reason, tor seems to want to re-open them regularly:
```
Jul 04 08:17:09.000 [warn] Could not open "/var/lib/tor/keys/ed25519_signing_secret_key": Permission denied
```
I...I keep my key files away from the running tor instance.
For some reason, tor seems to want to re-open them regularly:
```
Jul 04 08:17:09.000 [warn] Could not open "/var/lib/tor/keys/ed25519_signing_secret_key": Permission denied
```
It probably shouldn't want that.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19506Tool to inspect id signing certs2020-06-13T15:28:54Zweasel (Peter Palfrader)Tool to inspect id signing certsThere is no tool to figure out what is inside an ed25519_signing_cert file.
For monitoring purposes it's important we have a way to learn something like expiration date.There is no tool to figure out what is inside an ed25519_signing_cert file.
For monitoring purposes it's important we have a way to learn something like expiration date.Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/19303Revise {extend,create}_cell_format to use trunnel2020-06-13T14:58:22ZNick MathewsonRevise {extend,create}_cell_format to use trunnelAs part of the prop220 extend cell work, we'll be making these functions bigger. It's time to be safe and make them use trunnel.As part of the prop220 extend cell work, we'll be making these functions bigger. It's time to be safe and make them use trunnel.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19302Send ed25519 IDs in EXTEND2 cells2020-06-13T14:58:21ZNick MathewsonSend ed25519 IDs in EXTEND2 cellsOnce we have #19301 complete, we can update clients to generate circuits using ed25519 identities.
We'll have to actually store the ed25519 identity in the extend_cell_t when we make in .
We'll have to encode it as part of extend_cell...Once we have #19301 complete, we can update clients to generate circuits using ed25519 identities.
We'll have to actually store the ed25519 identity in the extend_cell_t when we make in .
We'll have to encode it as part of extend_cell_format.
We'll have to decide whether to use it: it's only okay to send the ed25519 ID when both servers support the new link handshake.
We can enable this with a tristate, for testing, and to make sure that this turns on for a big pile of clients at once.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19301Accept Ed25519 identities in EXTEND2 cells2020-06-13T14:58:20ZNick MathewsonAccept Ed25519 identities in EXTEND2 cellsOnce we have the link-connection part of prop220 implemented, we can start here, and allow relays to start accepting Ed25519 identities in their extend2 cells.
We'll have to update extend_cell_parse to handle these, and extend_cell_t to...Once we have the link-connection part of prop220 implemented, we can start here, and allow relays to start accepting Ed25519 identities in their extend2 cells.
We'll have to update extend_cell_parse to handle these, and extend_cell_t to contain them.
We'll have to update channel_get_for_extend to look up by the complete set of link specifiers.
We'll have to update channel_connect_for_circuit to accept an ed25519 ID, if it hasn't already.
And we'll have to update circuit_extend to handle all that properly.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17675sandbox: ed25519 key creating failed2020-06-13T14:51:25Zcypherpunkssandbox: ed25519 key creating failedtor 0.2.7.5 (x86-64) failed to create ed25519 key and stop when sandbox/seccomp support is enabled
```
sandbox_intern_string(): Bug: No interned sandbox parameter found for /var/lib/tor/data/keys/ed25519_signing_secret_key_encrypted (on ...tor 0.2.7.5 (x86-64) failed to create ed25519 key and stop when sandbox/seccomp support is enabled
```
sandbox_intern_string(): Bug: No interned sandbox parameter found for /var/lib/tor/data/keys/ed25519_signing_secret_key_encrypted (on Tor 0.2.7.5 )
sandbox_intern_string(): Bug: No interned sandbox parameter found for /var/lib/tor/data/keys/ed25519_signing_public_key (on Tor 0.2.7.5 )
Could not open "/var/lib/tor/data/keys/ed25519_signing_public_key": Permission denied
```Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17021Update FAQ entry about identity keys to mention ed25519 keys.2020-06-13T17:23:14ZNick MathewsonUpdate FAQ entry about identity keys to mention ed25519 keys.Tor: 0.2.8.x-finalSebastian HahnSebastian Hahnhttps://gitlab.torproject.org/legacy/trac/-/issues/16944We need a "never make or load an online master key" option2020-06-13T14:48:40ZNick MathewsonWe need a "never make or load an online master key" optionTor: 0.2.7.x-final