The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-08-23T15:16:34Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26158A little bug of circular path of Tor2021-08-23T15:16:34ZTracA little bug of circular path of TorIn order to defend the **circular-path** attacks, Tor relays detects the next hop and previous hop of a circuit through node-id and Ed25519-id.
However, when the Tor relay detects the previous node has the same Ed25519-id with next nod...In order to defend the **circular-path** attacks, Tor relays detects the next hop and previous hop of a circuit through node-id and Ed25519-id.
However, when the Tor relay detects the previous node has the same Ed25519-id with next node, it forgot to return -1, and continue to extend the circuit.
This might cause some loopholes for the circular-path.
```
/* Next, check if we're being asked to connect to the hop that the
* extend cell came from. There isn't any reason for that, and it can
* assist circular-path attacks. */
if (tor_memeq(ec.node_id,
TO_OR_CIRCUIT(circ)->p_chan->identity_digest,
DIGEST_LEN)) {
log_fn(LOG_PROTOCO[[Image()]]L_WARN, LD_PROTOCOL,
"Client asked me to extend back to the previous hop.");
return -1;
}
/* Check the previous hop Ed25519 ID too */
if (! ed25519_public_key_is_zero(&ec.ed_pubkey) &&
ed25519_pubkey_eq(&ec.ed_pubkey,
&TO_OR_CIRCUIT(circ)->p_chan->ed25519_identity)) {
log_fn(LOG_PROTOCOL_WARN, LD_PROTOCOL,
"Client asked me to extend back to the previous hop "
"(by Ed25519 ID).");
}
```
**Trac**:
**Username**: TBD.ChenTor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26156Undefined references to EVP_CIPHER_CTX_cleanup() with OpenSSL 1.1.0 no-deprec...2020-06-27T13:53:23ZTracUndefined references to EVP_CIPHER_CTX_cleanup() with OpenSSL 1.1.0 no-deprecatedOn my machine with OpenSSL 1.1.0 `no-deprecated', Tor 0.3.4.1-alpha fails to build. The failure happens when linking several utilities, with the following error:
```
src/common/libor-crypto.a(aes.o): In function `aes_cipher_free_':
/hom...On my machine with OpenSSL 1.1.0 `no-deprecated', Tor 0.3.4.1-alpha fails to build. The failure happens when linking several utilities, with the following error:
```
src/common/libor-crypto.a(aes.o): In function `aes_cipher_free_':
/home/quentin/Security/Code/Tor/tor/src/common/aes.c:121: undefined reference to `EVP_CIPHER_CTX_cleanup'
```
This appears to be due to _src/common/aes.c_ not #include-ing "compat_openssl.h", and thus not having the OPENSSL_1_1_API #define. Simply adding `#include "compat_openssl.h"` in _aes.c_ fixes the build.
I have also checked that building still succeeds against OpenSSL 1.0.1 and 1.0.2 with this modification.
**Trac**:
**Username**: laomaiwengTor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26155Bandwidth file Timestamp is the latest scanner result, not the file creation ...2021-02-18T15:34:40ZteorBandwidth file Timestamp is the latest scanner result, not the file creation timeThe bandwidth file timestamp should be the last time a relay was scanned. But we say it's the file creation time, which is wrong.
in torflow, the timestamp is actually the oldest of the most recent timestamps for all scanners:
https://g...The bandwidth file timestamp should be the last time a relay was scanned. But we say it's the file creation time, which is wrong.
in torflow, the timestamp is actually the oldest of the most recent timestamps for all scanners:
https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/aggregate.py#n409
(This is buggy in small networks, because the unmeasured node scanner may end up in a state where is never has any nodes to scan. But we are not fixing torflow bugs.)
Here's how I suggest we fix the spec issue:
Replace the initial Timestamp with:
```
Timestamp NL
[At start, exactly once.]
The Unix Epoch time in seconds of the most recent scanner result.
If there are multiple scanners which can fail independently, implementations
SHOULD take the most recent timestamp from each scanner and use the
oldest value. This ensures all the scanners continue running.
If there are scanners that do not run continuously, they SHOULD be excluded
from the timestamp calculation,
It does not follow the KeyValue format for backwards
compatibility with version 1.0.0.
```
Add a file creation date:
```
"file_created=" DateTime NL
[Zero or one time.]
The date and time timestamp in ISO 8601 format and UTC time zone
when the file was created.
This Line has been added in version 1.1.0 of this specification.
```
Add a latest bandwidth in human-readable format:
```
"latest_bandwidth=" DateTime NL
[Zero or one time.]
The date and time timestamp in ISO 8601 format and UTC time zone
of the most recent scanner result.
This time MUST be identical to the initial Timestamp line.
This duplicate value is included to make the format easier for people
to read.
This Line has been added in version 1.1.0 of this specification.
```Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26152Improve errors on crypto/openssl_version badness2020-06-27T13:53:23ZNick MathewsonImprove errors on crypto/openssl_version badnessWhen these tests fail, they currently do so in an unhelpful way. They should log the offending strings when the version strings don't match.
Extracted from legacy/trac#25549.When these tests fail, they currently do so in an unhelpful way. They should log the offending strings when the version strings don't match.
Extracted from legacy/trac#25549.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26142replace uses of U64_* and I64_* macros with their C99 stdint.h or inttypes.h ...2021-09-16T14:30:20ZTaylor Yureplace uses of U64_* and I64_* macros with their C99 stdint.h or inttypes.h equivalentsThere are many macros in compat.h that try to portably handle 64-bit integer values in `printf()` and `scanf()` calls. Now that we seem to require C99, we should use the equivalent macros from stdint.h or inttypes.h instead. For exampl...There are many macros in compat.h that try to portably handle 64-bit integer values in `printf()` and `scanf()` calls. Now that we seem to require C99, we should use the equivalent macros from stdint.h or inttypes.h instead. For example, `U64_FORMAT` is equivalent to `PRIu64` in inttypes.h.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26139start aplication2020-07-28T19:15:45ZTracstart aplication[Sun May 20 08:50:50 2018] Tor Software Error - The Tor software encountered an internal bug. Please report the following error message to the Tor developers at bugs.torproject.org: "Bug: 8 tor 0x000...[Sun May 20 08:50:50 2018] Tor Software Error - The Tor software encountered an internal bug. Please report the following error message to the Tor developers at bugs.torproject.org: "Bug: 8 tor 0x00000001065c9786 tor_main + 70 (on Tor 0.3.3.5-rc 81d71f0d41adf0d8)
"
**Trac**:
**Username**: xrootersTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26138DirPort /tor/server/all document contains spurrious blank line following serv...2020-07-28T19:13:56ZstarlightDirPort /tor/server/all document contains spurrious blank line following serving relay's descriptorissuing
```
curl -s http://x.x.x.x:x/tor/server/all.z | openssl zlib -d | less -SX
```
as expected retrieves a complete set of server descriptors; contains one blank line immediately after the descriptor of the serving relay which is n...issuing
```
curl -s http://x.x.x.x:x/tor/server/all.z | openssl zlib -d | less -SX
```
as expected retrieves a complete set of server descriptors; contains one blank line immediately after the descriptor of the serving relay which is not expected
trivial issue, but noticed it so reported it
glitch appears in 0.3.3 as wellTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26137Integrate AS-aware circuit selection2020-07-28T19:13:45ZcypherpunksIntegrate AS-aware circuit selectionThe "ASToria" Tor client has been available since 2015, but I haven't seen any analysis of it from Tor Project or any plans to integrate any of the ideas. The general idea behind ASToria is to improve path selection to minimize the risk ...The "ASToria" Tor client has been available since 2015, but I haven't seen any analysis of it from Tor Project or any plans to integrate any of the ideas. The general idea behind ASToria is to improve path selection to minimize the risk of AS-level traffic correlation. It is effectively an enhanced version of Tor's current naïve path-selection behavior which simply involves avoiding circuits with relays that share too small of a subnet. This is a similar proposal to legacy/trac#10221, which was created before this paper was published.
Tor should integrate AS-aware circuit selection (whether by including the ASToria code or creating a bespoke solution), or at the very least integrate AS-aware circuit measurement to make potential transition easier in the future. Additionally, this change would require no modifications of the Tor protocol and would be completely backwards-compatible with the network. From the paper's abstract:
>We find that up to 40% of all circuits created by Tor are vulnerable to attacks by traffic correlation from Autonomous System (AS)-level adversaries, 42% from colluding AS-level adversaries, and 85% from state-level adversaries. In addition, we find that in some regions (notably, China and Iran) there exist many cases where over 95% of all possible circuits are vulnerable to correlation attacks, emphasizing the need for AS-aware relay-selection.
>
>Astoria reduces the number of vulnerable circuits to 2% against AS-level adversaries, under 5% against colluding AS-level adversaries, and 25% against state-level adversaries. In addition, Astoria load balances across the Tor network so as to not overload any set of relays.
Key points:
* The code has already been written and just needs a cleanup and some review.
* Load balancing is done to prevent individual relays from being overloaded.
* No changes to the protocol are needed, making this fully backwards-compatible.
* AS-level traffic analysis risk is reduced from 40% to 2% for any given circuit.
https://arxiv.org/abs/1505.05173
https://github.com/sbunrg/AstoriaTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26136DirPort reachability test inconsistency when only "DirPort x.x.x.x:x NoAdvert...2020-07-28T19:14:45ZstarlightDirPort reachability test inconsistency when only "DirPort x.x.x.x:x NoAdvertise" configuredIf relay starts with only NoAdvertise DirPorts configured, ~~bootstrapping fails~~ the relay's descriptor is never published:
```
Tor 0.3.4.1-alpha (git-deb8970a29ef7427) running on Linux with Libevent x.x.x, OpenSSL x.x.x, Zlib x.x.x, ...If relay starts with only NoAdvertise DirPorts configured, ~~bootstrapping fails~~ the relay's descriptor is never published:
```
Tor 0.3.4.1-alpha (git-deb8970a29ef7427) running on Linux with Libevent x.x.x, OpenSSL x.x.x, Zlib x.x.x, Liblzma x.x.x, and Libzstd x.x.x.
.
.
.
Opening Control listener on x.x.x.y:r
Opening OR listener on x.x.x.x:o
Opening Directory listener on x.x.x.y:d
.
.
.
Bootstrapped 80%: Connecting to the Tor network
Bootstrapped 85%: Finishing handshake with first hop
Bootstrapped 90%: Establishing a Tor circuit
Tor has successfully opened a circuit. Looks like client functionality is working.
Bootstrapped 100%: Done
Now checking whether ORPort x.x.x.x:o is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Requested exit point '$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' is not known. Closing.
Self-testing indicates your ORPort is reachable from the outside. Excellent.
Performing bandwidth self-test...done.
Requested exit point '$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' is not known. Closing.
Requested exit point '$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' is not known. Closing.
Requested exit point '$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' is not known. Closing.
Requested exit point '$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' is not known. Closing.
Requested exit point '$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' is not known. Closing.
Requested exit point '$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' is not known. Closing.
Your server (x.x.x.x:0) has not managed to confirm that its DirPort is reachable. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.
```
```
ORPort x.x.x.x:o
DirPort x.x.x.y:d NoAdvertise
ControlPort x.x.x.y:r
```Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26121BUILDTIMEOUT_SET totals are still off2020-06-27T13:53:24ZMike PerryBUILDTIMEOUT_SET totals are still offWhile testing and examining onion service timeout rates and trying to verify them from a controller script, I realized that our timeout rates are still off in the BUILDTIMEOUT_SET event.
The reason for the discrepancy is that we're doub...While testing and examining onion service timeout rates and trying to verify them from a controller script, I realized that our timeout rates are still off in the BUILDTIMEOUT_SET event.
The reason for the discrepancy is that we're double-counting circuits that transition into MEASUREMENT_EXPIRED. Every circuit that transitions into MEASUREMENT_EXPIRED is first counted as a timeout in circuit_build_times_mark_circ_as_measurement_only(). Of those that do not complete within the measurement window, we again count as a "closed" circuit in circuit_build_times_count_close(). If a measurement circuit succeeds, we do *not* count it as a success (see circuit_build_times_handle_completed_hop()).
This means that the total_circuits value in cbt_control_event_buildtimeout_set() should be timeouts+succeeded, and not timeouts+succeeded+closed. (Again, counting closed in the total there double-counts "closed" MEASUREMENT circuits, which were also counted as timeout circuits earlier).
Since this is just a control port stats change, it would be nice to get it into 0.3.4 (and maybe 0.3.3) so it is easier to get more accurate data about how the circuit build timeout is interacting with vanguards there.Tor: 0.3.4.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26117AF_UNSPEC are actually valid connected cells2020-06-27T13:53:24ZMike PerryAF_UNSPEC are actually valid connected cellsThe DELIVERED and OVERHEAD cell count in legacy/trac#25903 used the AF_UNSPEC check to represent validity. In legacy/trac#26072 we discovered that the connected cell processing was wrong. Also, AF_UNSPEC may be used for rend connects.
N...The DELIVERED and OVERHEAD cell count in legacy/trac#25903 used the AF_UNSPEC check to represent validity. In legacy/trac#26072 we discovered that the connected cell processing was wrong. Also, AF_UNSPEC may be used for rend connects.
Not in any released version of tor.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26116OpenSSL 1.1.1 changed the semantics of the password callback return value2020-06-27T13:53:25ZNick MathewsonOpenSSL 1.1.1 changed the semantics of the password callback return valueIn c82c3462267afdbbaa5, openssl changed its interpretation of getting a "0" result from a PEM password callback. Previously, this indicated an error, and the documentation said:
>The callback **must** return the number of characters i...In c82c3462267afdbbaa5, openssl changed its interpretation of getting a "0" result from a PEM password callback. Previously, this indicated an error, and the documentation said:
>The callback **must** return the number of characters in the passphrase or 0 if an error occurred.
But now, 0 means an empty passphrase, and -1 means that an error occurred.
To avoid strange bugs and compatibility issues, we should have our pem_no_password_cb function return -1 instead. (-1 was always a supported return value, even if it isn't documented.)Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26113Control spec is ambiguous whether a GETCONF error message is specified2020-07-31T14:03:27ZdmrControl spec is ambiguous whether a GETCONF error message is specifiedThe [[spec for `GETCONF` response](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt?id=436d08b49fb84aa62d7bc96013002a0c27534bbb#n307|control)] says:
```
If some of the listed keywords can't be found, Tor replies with a
...The [[spec for `GETCONF` response](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt?id=436d08b49fb84aa62d7bc96013002a0c27534bbb#n307|control)] says:
```
If some of the listed keywords can't be found, Tor replies with a
"552 unknown configuration keyword" message.
```
The spec also has a [[about error messages](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt?id=436d08b49fb84aa62d7bc96013002a0c27534bbb#n1809|clause)]:
```
Unless specified to have specific contents, the human-readable messages
in error replies should not be relied upon to match those in this document.
```
Unfortunately, it's unclear what //specified to have specific contents// means here. The message for `GETCONF` is quoted, which at least in cursory read made me think it was //specified//.
But I suppose it's ambiguous.
==== Expected change
In discussion over IRC, arma suggested it...
> might be even better to change the spec to be like "replies with a 552 message because of the unrecognized configuration key."
Overall, it was agreed upon amongst arma, meejah, sysrqb, and myself that the spec shouldn't be denoting a specific message here, and that controllers shouldn't rely on a specific message. Only the numeric code `552` should be relied upon.https://gitlab.torproject.org/tpo/core/tor/-/issues/26110CIRC_BW fields vague2020-06-27T13:53:25ZDamian JohnsonCIRC_BW fields vagueHi lovely network team folks. Yesterday Mike documented CIRC_BW's new fields...
https://gitweb.torproject.org/torspec.git/commit/?id=fbb38ec
This is great, but this isn't quite enough for me to grok what they are. "Bytes read and writt...Hi lovely network team folks. Yesterday Mike documented CIRC_BW's new fields...
https://gitweb.torproject.org/torspec.git/commit/?id=fbb38ec
This is great, but this isn't quite enough for me to grok what they are. "Bytes read and written on a circuit" is simple and clear, but "the total length of the unused overhead portion of valid relay cells" doesn't make sense to me.
I'll submit a patch in a minute I find clearer giving a rough guess at what I think these are, *but* my description will no doubt be inaccurate. Hopefully together we'll be able to come up with something both clear and correct. :)Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26109our crypto::digests crate isn't actually exported2020-06-27T13:53:25ZIsis Lovecruftour crypto::digests crate isn't actually exportedWe should probably make it `pub` somehow if we intend to use it.We should probably make it `pub` somehow if we intend to use it.Tor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/core/tor/-/issues/26108the FFI functions in crypto_rand.rs aren't actually exported2020-06-27T13:53:25ZIsis Lovecruftthe FFI functions in crypto_rand.rs aren't actually exportedTor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/core/tor/-/issues/26107move rand crate into parent crypto crate2020-06-27T13:53:25ZIsis Lovecruftmove rand crate into parent crypto crateThe crate at src/rust/rand should probably actually live at src/rust/crypto/randThe crate at src/rust/rand should probably actually live at src/rust/crypto/randTor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/core/tor/-/issues/26106bump rand dependency to 0.5.0-pre.22020-06-27T13:53:25ZIsis Lovecruftbump rand dependency to 0.5.0-pre.2This is blocking legacy/trac#23886, because the `rand_core::RngCore` and `rand::Rng` traits resolve as being different, because `curve25519-dalek` needs to use `0.5.0-pre.2` because it added `impl CryptoRng for OsRng` (which we also prob...This is blocking legacy/trac#23886, because the `rand_core::RngCore` and `rand::Rng` traits resolve as being different, because `curve25519-dalek` needs to use `0.5.0-pre.2` because it added `impl CryptoRng for OsRng` (which we also probably want but I did a workaround in legacy/trac#25508).Tor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/core/tor/-/issues/26105Perhaps, make test coverage deterministic _within_ lines2020-07-28T19:11:08ZNick MathewsonPerhaps, make test coverage deterministic _within_ linesSee legacy/trac#25907 and legacy/trac#26101 for background: apparently gcov now has a feature where it can tell us that a line was reached, but not every basic block within the line was reached.
Right now, our unit tests have two cases ...See legacy/trac#25907 and legacy/trac#26101 for background: apparently gcov now has a feature where it can tell us that a line was reached, but not every basic block within the line was reached.
Right now, our unit tests have two cases where sometimes a line is completely covered, and sometime the line is only partially covered:
```
--- a/workqueue.c.gcov.tmp
+++ /workqueue.c.gcov.tmp
@@ -198,7 +198,7 @@
1: tor_mutex_acquire(&ent->on_pool->lock);
1: workqueue_priority_t prio = ent->priority;
1: if (ent->pending) {
- 1*: TOR_TAILQ_REMOVE(&ent->on_pool->work[prio], ent, next_work);
+ 1: TOR_TAILQ_REMOVE(&ent->on_pool->work[prio], ent, next_work);
1: cancelled = 1;
1: result = ent->arg;
-: }
```
```
--- a/compat_pthreads.c.gcov.tmp
+++ /compat_pthreads.c.gcov.tmp
@@ -271,7 +271,7 @@
-: }
1: tvnow.tv_sec = ts.tv_sec;
1: tvnow.tv_usec = (int)(ts.tv_nsec / 1000);
- 1*: timeradd(tv, &tvnow, &tvsum);
+ 1: timeradd(tv, &tvnow, &tvsum);
-:#else /* !(defined(HAVE_CLOCK_GETTIME) && defined(USE_COND_CLOCK)) */
-: if (gettimeofday(&tvnow, NULL) < 0)
-: return -1;
```
Unless coveralls cares about these, I think solving the determinism here is not super-important, though it might be fun from a completionist perspective.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26104Update to May GeoIP2 database2020-06-27T13:53:26ZKarsten LoesingUpdate to May GeoIP2 database[My geoip-2018-05-01 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2018-05-01) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.9 and other branch...[My geoip-2018-05-01 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2018-05-01) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.9 and other branches that are still maintained.
(Note to self when I use this ticket as template for the next months: 0.3.1 is end of life on 1 July 2018.)Tor: 0.2.9.x-final