Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-09-01T21:29:26Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27047Authorities should keep recent consensuses, votes, and bandwidth files2022-09-01T21:29:26ZteorAuthorities should keep recent consensuses, votes, and bandwidth filesMoving https://trac.torproject.org/projects/tor/ticket/21378#comment:12 into a separate ticket:
Quoting teor:
> Replying to teor:
> > Replying to irl:
> > > Using the fixed URL http://<hostname>/tor/status-vote/next/bandwidth.z sounds ...Moving https://trac.torproject.org/projects/tor/ticket/21378#comment:12 into a separate ticket:
Quoting teor:
> Replying to teor:
> > Replying to irl:
> > > Using the fixed URL http://<hostname>/tor/status-vote/next/bandwidth.z sounds like it would be very easy to add this to CollecTor.
> >
> > Thanks for the feedback!
> >
> > > We have discussed in the Metrics team extending `dir-spec.txt` to allow to fetch "recent" files as well as just next/current. In the case that there is a wide CollecTor outage, and we miss a file, it would be good to have those files cached (on a best-effort basis, not necessarily persisted to disk) and available via some URL.
> >
> > How is this any different to losing descriptors or consensuses?
> > (Please answer this question on a separate ticket.)
> >
> > > I don't know if karsten already had some ideas about what these URLs would look like, but we should perhaps consider this before implementing changes to `dir-spec.txt`.
> >
> > Please open a separate ticket for this feature. It's potentially a large feature. And it's not essential for the initial release of this feature.
>
> If you open a separate ticket for historical directory documents, please make legacy/trac#26698 a child of that ticket. We'll need bandwidth file hashes to work out the exact file used in each vote.https://gitlab.torproject.org/tpo/core/tor/-/issues/19162Make it even harder to become HSDir2023-03-13T09:57:24ZGeorge KadianakisMake it even harder to become HSDirIn legacy/trac#8243 we started requiring `Stable` flag for becoming HSDirs, but this is still not hard enough for motivated adversaries. Hence we need to make it even harder for a relay to become HSDir, so that only relays that have been...In legacy/trac#8243 we started requiring `Stable` flag for becoming HSDirs, but this is still not hard enough for motivated adversaries. Hence we need to make it even harder for a relay to become HSDir, so that only relays that have been around for long get the flag. After prop224 gets deployed, there will be less incentive for adversaries to become HSDirs since they won't be able to harvest onion addresses.
Until then, our current plan is to increase the bandwidth and uptime required to become an HSDir to something almost unreasonable. For example requiring an uptime of over 6 months, or maybe requiring that the relay is in the top 1/4th of uptimes on the network.Tor: unspecifiedRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/19069When DisableNetwork is 1 but !circuit_enough_testing_circs(), we can still la...2022-06-24T16:12:14ZRoger DingledineWhen DisableNetwork is 1 but !circuit_enough_testing_circs(), we can still launch circuitsIn consider_testing_reachability(), we check
```
if (test_or && (!orport_reachable || !circuit_enough_testing_circs())) {
```
Once legacy/trac#18616 is merged, the first function will return 1 for orport_reachable when DisableNetwork ...In consider_testing_reachability(), we check
```
if (test_or && (!orport_reachable || !circuit_enough_testing_circs())) {
```
Once legacy/trac#18616 is merged, the first function will return 1 for orport_reachable when DisableNetwork is 1, so that bug will go away.
But it will remain the case that if !circuit_enough_testing_circs(), we will proceed to call circuit_launch_by_extend_info(), even when DisableNetwork is 1.
There are four places that call consider_testing_reachability():
* circuitbuild.c:circuit_send_next_onion_skin()
* circuituse.c:circuit_testing_opened()
* main.c:directory_info_has_arrived()
* main.c:check_for_reachability_bw_callback()
I think the middle two are safe, since they shouldn't happen while DisableNetwork is set.
I think the first one is iffy, since it's called from a bunch of places so I'm not sure, but given the name I hope it doesn't get called during DisableNetwork.
And I think the fourth one is bad news, since it gets called periodically and doesn't check DisableNetwork.https://gitlab.torproject.org/tpo/core/tor/-/issues/15469Remove data structure containing unique IP address sets2022-06-24T14:45:34ZKarsten LoesingRemove data structure containing unique IP address setsRelays keep a data structure of unique connecting IP addresses for statistics and for informational purposes.
We should consider removing that data structure. There's a privacy risk in gathering unique IP address sets in memory and in ...Relays keep a data structure of unique connecting IP addresses for statistics and for informational purposes.
We should consider removing that data structure. There's a privacy risk in gathering unique IP address sets in memory and in reporting aggregate statistics based on them. If we don't need these statistics, we should stop reporting them and stop gathering the underlying data.
The main (and only?) data structure containing unique IP address sets is `clientmap` in `src/or/geoip.c`. If we remove that data structure, we would also have to remove:
1. the `dirreq-v3-ips` line from extra-info descriptors,
2. all "bridge statistics" including `bridge-stats-end`, `bridge-ips`, `bridge-ip-versions`, and `bridge-ip-transports` lines from extra-info descriptors,
3. all "entry node statistics" including `entry-stats-end` and `entry-ips` from extra-info descriptors,
4. the log line `"Heartbeat: In the last %d hours, I have seen %d unique clients."`, and
5. the `CLIENTS_SEEN` controller event.
1 and 3 are not used. 2 is used by Metrics to estimate the number of daily bridge users, and we'd need to implement legacy/trac#8786 before removing bridge statistics. atagar thinks that 4 was added by Sebastian a few years back, so that relay operators with certain simple use cases don't need to open a control port and run something like arm. 5 is used by arm for one of its dialogs, and atagar thinks it's not the end of the world to lose that.
Thoughts?https://gitlab.torproject.org/tpo/core/tor/-/issues/13987Apply laplace noise to other statistics2022-09-01T21:32:18ZNick MathewsonApply laplace noise to other statisticsIn legacy/trac#13192, we included a facility to obscure hidden service stats by adding laplace noise. What do think about applying laplace noise to the other statistics we report?In legacy/trac#13192, we included a facility to obscure hidden service stats by adding laplace noise. What do think about applying laplace noise to the other statistics we report?https://gitlab.torproject.org/tpo/core/tor/-/issues/7962Which address should a multi-ORPort Tor put in its "transport" extra-info line?2022-02-21T19:33:17ZGeorge KadianakisWhich address should a multi-ORPort Tor put in its "transport" extra-info line?https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/dir-spec.txt#L907
When a bridge advertises its pluggable transports to BridgeDB, it adds its external IP address in its "transport" line in its extrainfo descriptor.
We should ...https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/dir-spec.txt#L907
When a bridge advertises its pluggable transports to BridgeDB, it adds its external IP address in its "transport" line in its extrainfo descriptor.
We should clearly spec out what a bridge should put in its "transport" line when it has multiple OR addresses.https://gitlab.torproject.org/tpo/core/tor/-/issues/7870Retry on a new circuit for more reasons.2023-04-03T16:41:58ZRoger DingledineRetry on a new circuit for more reasons.In git commit 388ac4126 I added some code that will never be reached:
```
if (rh->length > 0 && edge_reason_is_retriable(reason) &&
[...]
case END_STREAM_REASON_CONNECTREFUSED:
if (!conn->chosen_exit_optional)
b...In git commit 388ac4126 I added some code that will never be reached:
```
if (rh->length > 0 && edge_reason_is_retriable(reason) &&
[...]
case END_STREAM_REASON_CONNECTREFUSED:
if (!conn->chosen_exit_optional)
break; /* break means it'll close, below */
/* Else fall through: expire this circuit, clear the
* chosen_exit_name field, and try again. */
[...]
case END_STREAM_REASON_TIMEOUT:
```
since those two reasons aren't included in edge_reason_is_retriable().
One fix would be just to remove those dead code lines.
But another fix would be to include both of those reasons in the is_retriable() list, to better tolerate broken exits -- for example, an exit that sets -j REJECT in an iptable rule, rather than putting everything in its exit policy; or an exit for which the routing to the destination has a loop, causing the ttl to expire and some internet router to send back an icmp unreachable.
The downsides are a) if will take many seconds longer before your connection fails, if it fails, and b) we throw away circuits even more often, since we'll now chew through several circuits every time you attempt a destination that is down or unreachable.
The upside is that users will see fewer false failures, in proportion to how many broken or misconfigured exits there are.
I'm not entirely sure which side of the fence I'm on here. I think I lean slightly towards retrying for these two cases.https://gitlab.torproject.org/tpo/core/tor/-/issues/1238Exit flag assigned can be assigned to nodes that don't really exit.2021-09-27T16:51:52ZSebastian HahnExit flag assigned can be assigned to nodes that don't really exit.The router b0red is flagged as Exit, even though its Exit policy doesn't allow any exits.
Discovered by "dun" on #tor.
This is currently part of the consensus:
```
r b0red WCi6nB/t0u9ZtGBcrrWFgpXdjlg w+3Dl7l2fnUc0JhSMLchCL7RcjU 2010-0...The router b0red is flagged as Exit, even though its Exit policy doesn't allow any exits.
Discovered by "dun" on #tor.
This is currently part of the consensus:
```
r b0red WCi6nB/t0u9ZtGBcrrWFgpXdjlg w+3Dl7l2fnUc0JhSMLchCL7RcjU 2010-02-02 00:21:48 80.190.250.90 443 80
s Exit Fast Guard HSDir Named Running Stable V2Dir Valid
v Tor 0.2.1.20
w Bandwidth=621
p reject 1-65535
```
descriptor:
```
@downloaded-at 2010-01-31 23:16:54
@source "194.109.206.212"
router b0red 80.190.250.90 443 0 80
platform Tor 0.2.1.20 on Linux i686
opt protocols Link 1 2 Circuit 1
published 2010-01-31 12:20:43
opt fingerprint 5828 BA9C 1FED D2EF 59B4 605C AEB5 8582 95DD 8E58
uptime 5097747
bandwidth 5242880 10485760 261098
opt extra-info-digest 535CE872B386F71E9DEA356B10E63E9D83789F57
onion-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAM2wCZqUMEgPDdEsVrW1XfHrvqmOT1KYDMupz7h+DA5b56VMPOIyOG57
hKGliyW5gE7B/Qtt5EtasScqAFM+kV9BVXWVshFEF4tu2kWdFS8E4XKVks0NbTUU
2H/l0W/H2KdMy1bUuWyd7s1ftcuodb04Na3U/DS0t26Ta1kADWLZAgMBAAE=
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBANB7P5x+7SON1dd2RkuqjNZaPsSPKoGKIOuq1IwSNDJR8+Y7T7jijgWe
ZKzvieP82XK1eDxKTdXCJbWR1X+V5a5XExt8RNszeslK02bC+Q4wTUtlM7n3319Q
UQrLTp++dVLa0LuNvlbux39tqAqriyn0hWI2JVEbkrp32N4l28SFAgMBAAE=
-----END RSA PUBLIC KEY-----
opt hidden-service-dir
opt allow-single-hop-exits
contact xxoes <xxoes at b0red.de>
reject 0.0.0.0/8:*
reject 169.254.0.0/16:*
reject 127.0.0.0/8:*
reject 192.168.0.0/16:*
reject 10.0.0.0/8:*
reject 172.16.0.0/12:*
reject 80.190.250.90:*
reject *:1-65534
reject *:65535
accept *:*
router-signature
-----BEGIN SIGNATURE-----
SVmtJeKcTUVyaZO8PfKtd0E1yQUR+TffgNo5AAgPOGLdjqmbIpFA2RqsfFqXK2Re
PQ34TxbgMKGxfZKDVXAfeQFVVQgFny8KqAlzDfytFUxOGvdcthHsfg/FJwbPneNU
eiNdn4E+ug8JjOcAKJ7EdfhmIKaWRXAg2NKZKWbNnRQ=
-----END SIGNATURE-----
```