Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2022-06-24T14:25:41Zhttps://gitlab.torproject.org/legacy/trac/-/issues/25705Refactor circuit_build_failed to separate build vs path failures2022-06-24T14:25:41ZMike PerryRefactor circuit_build_failed to separate build vs path failuresWe should not give up on the network, our TLS conn, or our guard in the event of path failures (which can happen if we're low on mds, and/or if the user set a bunch of path-restricting torrc options).
I think this might want to be a bac...We should not give up on the network, our TLS conn, or our guard in the event of path failures (which can happen if we're low on mds, and/or if the user set a bunch of path-restricting torrc options).
I think this might want to be a backport. It should also handle #25347.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25573Track half-closed stream IDs2022-03-22T13:18:09ZMike PerryTrack half-closed stream IDsIn order to eliminate a side channel attack described in https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf ("DropMark" attack) we need a way to determine if a stream id is invalid.
Many clients (particularly Firefox...In order to eliminate a side channel attack described in https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf ("DropMark" attack) we need a way to determine if a stream id is invalid.
Many clients (particularly Firefox) will hang up on streams that still have data in flight. In this case, Tor clients send RELAY_COMMAND_END when they are done with a stream, and immediately remove that stream ID from their valid stream mapping. The remaining application data continues to arrive, but is silently dropped by the Tor client. The result is that this ignored stream data currently can't be distinguished from injected dummy traffic with completely random stream IDs, and this fact can be used to mount side channel attacks.
A similar situation exists for spurious RELAY_ENDs.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20916Proposal: Put Relay IPv6 Addresses in the microdesc consensus2020-06-13T18:14:17ZteorProposal: Put Relay IPv6 Addresses in the microdesc consensusThe relay wedostor is bound to an unreachable IPv6 address.
https://atlas.torproject.org/#details/F70B7C5CD72D74C7F9F2DC84FA9D20D51BA13610
(Atlas shows no IPv6 address.)
It advertises the IPv6 address in its descriptor:
http://46.28.109...The relay wedostor is bound to an unreachable IPv6 address.
https://atlas.torproject.org/#details/F70B7C5CD72D74C7F9F2DC84FA9D20D51BA13610
(Atlas shows no IPv6 address.)
It advertises the IPv6 address in its descriptor:
http://46.28.109.231:9030/tor/server/authority
The full consensus has no IPv6 address:
http://collector.torproject.org/recent/relay-descriptors/consensuses/2016-12-07-11-00-00-consensus
But the microdesc does have the IPv6 address:
http://46.28.109.231:9030/tor/micro/d/Z7YTOuC8gXcelqDlUhpsvaTPLp04QhyEXvOWo1inWj8
And strangely, no client I have access to seems to download this microdescriptor. Maybe it registers as invalid somehow?
A fix to this will require a new consensus method.Tor: unspecifiedteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/28305Include client numbers even if we think we got reports from more than 100% of...2020-06-13T18:09:30ZKarsten LoesingInclude client numbers even if we think we got reports from more than 100% of all relaysThe estimated fraction of reported user statistics from relays has reached 100% and even went slightly beyond that number to 100.294% on 2018-10-27 and 100.046% on 2018-10-28.
The effect is that we're excluding days when this happened f...The estimated fraction of reported user statistics from relays has reached 100% and even went slightly beyond that number to 100.294% on 2018-10-27 and 100.046% on 2018-10-28.
The effect is that we're excluding days when this happened from statistics, because we never thought this was possible:
```
WHERE a.frac BETWEEN 0.1 AND 1.0
```
However, I think this is most likely a rounding error somewhere, not a general issue with the approach. Stated differently, it seems wrong to include a number with a fraction of reported statistics of 99.9% but not one where that fraction is 100.1%.
I suggest that we drop the upper limit and change the line above to:
```
WHERE a.frac >= 0.1
```
We'll be replacing these statistics by PrivCount in the medium term anyway.
However, simply excluding data points doesn't seem like an intuitive solution.
Thoughts?Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/29018Make all statistics depend on ExtraInfoStatistics2020-06-13T15:42:53ZteorMake all statistics depend on ExtraInfoStatisticsLike #29017, when a user sets ExtraInfoStatistics 0, they probably don't want any statistics in their extra-info document.Like #29017, when a user sets ExtraInfoStatistics 0, they probably don't want any statistics in their extra-info document.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29017PaddingStatistics should be disabled when ExtraInfoStatistics is 02020-06-13T15:36:26ZteorPaddingStatistics should be disabled when ExtraInfoStatistics is 0The man page entry for PaddingStatistics says that it is disabled when ExtraInfoStatistics is 0. But that isn't the case: the statistics are published regardless of ExtraInfoStatistics.
As far as I can tell, PaddingStatistics are collec...The man page entry for PaddingStatistics says that it is disabled when ExtraInfoStatistics is 0. But that isn't the case: the statistics are published regardless of ExtraInfoStatistics.
As far as I can tell, PaddingStatistics are collected on bridges, but the man page says "Relays only."Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/27199panic inside rust extern "C" function is undefined behavior2020-06-13T15:29:38ZTracpanic inside rust extern "C" function is undefined behavior`panic="abort"` needs to be set for all profiles in Cargo.toml, at least until the upstream bug is fixed: https://github.com/rust-lang/rust/issues/52652
This is already set for `[profile.release]` builds, but not for the others.
**Trac...`panic="abort"` needs to be set for all profiles in Cargo.toml, at least until the upstream bug is fixed: https://github.com/rust-lang/rust/issues/52652
This is already set for `[profile.release]` builds, but not for the others.
**Trac**:
**Username**: cyberpunksTor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/26958Privcount blinding and encryption: run clippy on travis rust nightly2020-06-13T15:28:48ZteorPrivcount blinding and encryption: run clippy on travis rust nightlyWe'll need to fix or disable a lot of warnings for clippy.We'll need to fix or disable a lot of warnings for clippy.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24546Use tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4 addresses2020-06-13T15:26:54ZteorUse tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4 addressesIn Tor, we try to support v6-mapped IPv4 addresses.
We should either:
* reject them unconditionally, or
* audit all uses of tor_addr_t.family to see if we should be calling tor_addr_is_v4() instead, and add a comment to the struct that s...In Tor, we try to support v6-mapped IPv4 addresses.
We should either:
* reject them unconditionally, or
* audit all uses of tor_addr_t.family to see if we should be calling tor_addr_is_v4() instead, and add a comment to the struct that says we should consider using tor_addr_is_v4() rather than comparing family.
If no relay in the consensus is currently using these addresses, then maybe we should just call them internal on authorities, relays, and clients, and remove all the code that tries to deal with them.
Discovered as part of #15518.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26378test_rust.sh fails on src/rust/crypto2020-06-13T15:26:43ZGeorge Kadianakistest_rust.sh fails on src/rust/cryptoThe latest travis builds fail on the rust tests after #26258 got merged (i guess). Here are some fails:
```
--> external/crypto_digest.rs:74:1
|
74 | const N_DIGEST_ALGORITHMS: usize = DIGEST_SHA3_512 as usize + 1;
| ^^^^^^^^^^^...The latest travis builds fail on the rust tests after #26258 got merged (i guess). Here are some fails:
```
--> external/crypto_digest.rs:74:1
|
74 | const N_DIGEST_ALGORITHMS: usize = DIGEST_SHA3_512 as usize + 1;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(dead_code)] on by default
warning: type alias is never used: `smartlist_t`
--> external/crypto_digest.rs:120:1
|
120 | type smartlist_t = Stringlist;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
warning: constant item is never used: `N_DIGEST_ALGORITHMS`
--> external/crypto_digest.rs:74:1
|
74 | const N_DIGEST_ALGORITHMS: usize = DIGEST_SHA3_512 as usize + 1;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(dead_code)] on by default
warning: type alias is never used: `smartlist_t`
--> external/crypto_digest.rs:120:1
|
120 | type smartlist_t = Stringlist;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Finished dev [unoptimized + debuginfo] target(s) in 3.39 secs
Running /home/travis/build/torproject/tor/tor-0.3.4.2-alpha-dev/_build/src/rust/target/debug/deps/external-99409f0e61b6d8c2
```
See https://api.travis-ci.org/v3/job/392350333/log.txt etc.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/26267export rand from the crypto crate2020-06-13T15:26:11ZIsis Lovecruftexport rand from the crypto crateIn #26107, it appears I forgot to add
```
pub mod rand;
```
in `src/rust/crypto/lib.rs`. This is possibly causing #26245.In #26107, it appears I forgot to add
```
pub mod rand;
```
in `src/rust/crypto/lib.rs`. This is possibly causing #26245.Tor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/26214Check stream SENDME against max2020-06-13T15:26:01ZMike PerryCheck stream SENDME against maxIn connection_edge_process_relay_cell() under the RELAY_COMMAND_SENDME handling, we check the circuit-level sendme against the window START_MAX, but we do not check the stream level SENDME against any max
This means that an attacker can...In connection_edge_process_relay_cell() under the RELAY_COMMAND_SENDME handling, we check the circuit-level sendme against the window START_MAX, but we do not check the stream level SENDME against any max
This means that an attacker can send as many stream-level sendme's on a circuit as they like, inflating the stream window as large as they like. This might be a serious OOM bug, but the circuit level SENDME check should prevent that, I think.
Even so, it would be nice to fix this in 0.3.4, so that the vanguards script's detection of invalid/dropped circuit data is more accurate.Tor: 0.3.4.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/26109our crypto::digests crate isn't actually exported2020-06-13T15:25:43ZIsis 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/legacy/trac/-/issues/26108the FFI functions in crypto_rand.rs aren't actually exported2020-06-13T15:25:43ZIsis Lovecruftthe FFI functions in crypto_rand.rs aren't actually exportedTor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/26107move rand crate into parent crypto crate2020-06-13T15:25:42ZIsis 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/legacy/trac/-/issues/26106bump rand dependency to 0.5.0-pre.22020-06-13T15:25:42ZIsis Lovecruftbump rand dependency to 0.5.0-pre.2This is blocking #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 b...This is blocking #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 #25508).Tor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/25381Add crypto_rand_double_sign() in C and Rust2020-06-13T15:22:33ZteorAdd crypto_rand_double_sign() in C and RustWe need a function that returns 1.0 or -1.0 with equal probability, so we can avoid weird tricks that waste floating point precision.
Since we want to use this in the laplace and guassian distributions, it needs to be implemented in bot...We need a function that returns 1.0 or -1.0 with equal probability, so we can avoid weird tricks that waste floating point precision.
Since we want to use this in the laplace and guassian distributions, it needs to be implemented in both C and Rust.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/13837Mitigate guard discovery by pinning middle node2020-06-13T15:20:48ZGeorge KadianakisMitigate guard discovery by pinning middle nodeHello,
inspired by the recent discussions on guard discovery, I went ahead
and implemented a small patch for Tor that tries to help defend
against Hidden Service guard discovery attacks.
It basically allows the operator to specify a se...Hello,
inspired by the recent discussions on guard discovery, I went ahead
and implemented a small patch for Tor that tries to help defend
against Hidden Service guard discovery attacks.
It basically allows the operator to specify a set of nodes that will
be pinned as middle nodes in Hidden Service rendezvous circuits. The
option only affects HS rendezvous circuits and nothing else.
Of course, it doesn't fix guard discovery, it just pushes guard
discovery to the next hop, so that they need to compromise two boxes
to win.
You can find my branch in 'sticky_mids' at
https://git.torproject.org/user/asn/tor.git .
(Here it is in HTTP shape:
https://gitweb.torproject.org/user/asn/tor.git/shortlog/refs/heads/sticky_mids )
[This is the trac version of https://lists.torproject.org/pipermail/tor-dev/2014-November/007730.html]Tor: 0.3.3.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/24929Maybe load balance pinned middles?2020-06-13T15:20:47ZMike PerryMaybe load balance pinned middles?Roger pointed out that people may specify entire countries or multiple countries for #13837, and may be surprised that tor doesn't load balance properly in this case. We may want to do load balancing here, if the list of selected nodes e...Roger pointed out that people may specify entire countries or multiple countries for #13837, and may be surprised that tor doesn't load balance properly in this case. We may want to do load balancing here, if the list of selected nodes exceeds K for some K.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23577Add rendezvous point IPv6 address to client introduce cells2020-06-13T15:20:29ZteorAdd rendezvous point IPv6 address to client introduce cellsTo provide both IPv4 and IPv6 addresses, setup_introduce1_data() needs to take a node, and we need to create a new get_lspecs_from_node() function.To provide both IPv4 and IPv6 addresses, setup_introduce1_data() needs to take a node, and we need to create a new get_lspecs_from_node() function.Tor: 0.3.3.x-final