- tor-dev - lists.torproject.org

Proposal 342: Decouple hs_interval and SRV lifetime
by Nick Mathewson 24 Jan '23

24 Jan '23

``` Filename: 342-decouple-hs-interval.md Title: Decoupling hs_interval and SRV lifetime Author: Nick Mathewson Created: 9 January 2023 Status: Draft ``` # Motivation and introduction Tor uses shared random values (SRVs) in the consensus to determine positions of relays within a hash ring. Which shared random value is to be used for a given time period depends upon the time at which that shared random value became valid. But right now, the consensus voting period is closely tied to the shared random value voting cycle: and clients need to understand both of these in order to determine when a shared random value became current. This creates tight coupling between: * The voting schedule * The SRV liveness schedule * The hsdir_interval parameter that determines the length of the an HSDIR index To decouple these values, this proposal describes a forward compatible change to how Tor reports SRVs in consensuses, and how Tor decides which hash ring to use when. ## Reporting SRV timestamps In consensus documents, parties should begin to accept `shared-rand-*-value` lines with an additional argument, in the format of an IsoTimeNospace timestamp (like "1985-10-26T00:00:00"). When present, this timestamp indicates the time at which the given shared random value first became the "current" SRV. Additionally, we define a new consensus method that adds these timestamps to the consensus. We specify that, in the absence of such a timestamp, parties are to assume that the `shared-rand-current-value` SRV became "current" at the first 00:00 UTC on the UTC day of the consensus's valid-after timestamp, and that the `shard-rand-previous-value` SRV became "current" at 00:00 UTC on the previous UTC day. ## Generalizing HSDir index scheduling. Under the current HSDir design, there is one SRV for each time period, and one time period for which each SRV is in use. Decoupling `hsdir_interval` from 24 hours will require that we change this notion slightly. We therefore propose this set of generalized directory behavior rules, which should be equivalent to the current rules under current parameters. The calculation of time periods remains the same (see `rend-spec-v3.txt` section `[TIME PERIODS]`). A single SRV is associated with each time period: specifically, the SRV that was "current" at the start of the time period. There is a separate hash ring associated with each time period and its SRV. Whenever fetching an onion service descriptor, the client uses the hash ring for the time period that contains the start of the liveness interval of the current consensus. Call this the "Consensus" time period. Whenever uploading an onion service descriptor, the service uses _two or three_ hash rings: * The "consensus" time period (see above). * The immediately preceding time period, if the SRV to calculate that hash ring is available in the consensus. * The immediately following time period, if the SRV to calculate that hash ring is available in the consensus. (Under the current parameters, where `hsdir_interval = SRV_interval`, there will never be more than two possible time periods for which the service can qualify.) ## Migration We declare that, for at least the lifetime of the C tor client, we will not make any changes to the voting interval, the SRV interval, or the `hsdir_interval`. As such, we do not need to prioritize implementing these changes in the C client: we can make them in Arti only. ## Issues left unsolved There are likely other lingering issues that would come up if we try to change the voting interval. This proposal does not attempt to solve them. This proposal does not attempt to add flexibility to the SRV voting algorithm itself. Changing `hsdir_interval` would create a flag day where everybody using old and new values of `hsdir_interval` would get different hash rings. We do not try to solve that here. ## Acknowledgments Thanks to David Goulet for explaining all of this stuff to me!

4 7

Tor Bridges and Snowflakes detection attack
by tor＠nullvoid.me 09 Jan '23

09 Jan '23

Hi, https://github.com/scriptzteam/Tor-Bridges-Collector Seems an attacker has found a way to enumerate ~300000 snowflakes and many bridges. I couldn't find any discussion about this in the archive. Thanks,

4 4

Typo in relay metrics (circs_creared)
by Andreas Bollhalder 09 Jan '23

09 Jan '23

Hi I think, there's a typo in the file "src/feature/relay/relay_metrics.c". Shouldn't the word "circs_creared" in the line metrics_format_label("action", "circs_creared")); be read as "circs_cleared"? Andreas PS: Sorry, at the moment I've no clue what would be the correct way to send patches...

2 2

C99 compatibility issue in torsocks
by Florian Weimer 17 Dec '22

17 Dec '22

This patch is needed to avoid an implicit function declaration: diff --git a/src/common/config-file.h b/src/common/config-file.h index 23e1c89d488b789c..e710c202fe099f61 100644 --- a/src/common/config-file.h +++ b/src/common/config-file.h @@ -109,6 +109,7 @@ int conf_file_set_allow_inbound(const char *val, struct configuration *config); int conf_file_set_allow_outbound_localhost(const char *val, struct configuration *config); int conf_file_set_isolate_pid(const char *val, struct configuration *config); +int conf_file_set_enable_ipv6(const char *val, struct configuration *config); int conf_apply_socks_auth(struct configuration *config); I'm not sure where the canonical upstream for this package is, so I'm reporting it here. Fedora is tracking this here: torsocks: Missing declaration in src/common/config-file.h <https://bugzilla.redhat.com/show_bug.cgi?id=2154535> Related to: <https://fedoraproject.org/wiki/Changes/PortingToModernC> <https://fedoraproject.org/wiki/Toolchain/PortingToModernC>

2 1

Applications team no longer updating gitolite repos
by Richard Pospesel 06 Dec '22

06 Dec '22

Hi everyone, With the 12.0 release almost out the door, the applications team will no longer be pushing commits to our git.torproject.org (gitolite) repos. All future code updates will only be pushed to our various gitlab.torproject.org (Gitlab) repos. best, -Richard

1 0

Latest releases missing from changelog
by Michael Rogers 09 Nov '22

09 Nov '22

Hi all, The latest releases (0.4.7.10, 0.4.6.12 and 0.4.5.14) seem to be missing from the changelog: https://gitlab.torproject.org/tpo/core/tor/-/raw/main/ChangeLog Is this file still the right place to look? Cheers, Michael

2 1

Release new version of stem
by Hefee 03 Oct '22

03 Oct '22

Hey, nodens(nodens(a)debian.org) and me are currently packaging the new version of onionshare for Debian and stumbled over the dependency cepa[1], what is a fork of stem. After digging deeper into it, I found out, that the main reason why they do so is the support for Client Auth v3 onions[2]. I really would like not to package a fork of stem, if possible. That's why I ask, when it is planed to release a new version of stem? It hasn't seen any release since 2019 and there are a lot of changes in master branch too. Maybe you can just release the current state of the maint branch, that is actually what is released as cepa 1.8.3. I some how need to solve this till January, when Debian is freezing (not accepting new versions). Regards hefee [1] https://github.com/onionshare/cepa [2] https://github.com/torproject/stem/commit/ 2f3bbf64b4ce3b63160a3c56b15748ba626de4a0

5 8

Blacklist all domains, whitelist .onion,.exit
by nyxnor 21 Sep '22

21 Sep '22

Hello. I am trying to make a tor only allow traffic through onion services and exit nodes. I would like to blacklist all domains first, as that is simple and does not need to be updated, then whitelist all onions and exits. Reason: I am hosting an onion service, but I don't want any client traffic comming from that machine. I've played with MapAddress, VirtualAddrNetworkIPV4, AutomapHostsOnResolve, AutomaptHostsSuffixes, but nothing seems to work as intended above. MapAddress *=127.0.0.1 does not report invalid conf, but the controller reports it is using invalid sytax because "*" be source or target. I tricked the controller with MapAddress *.*=127.0.0.1, as every domain has a dot, the controller didn't report syntax error and this option is actually ignored. If the above worked, then the next option would be the whitelisting: MapAddress *.onion VIRTUAL_IP Or possibly the AutomapHostsOnResolve 1 and AutomapHostsSuffixes .exit,.onion would handle that part hopefully. I did the lazy way, the antivirus way, I downloaded the IANA TLD domain list and used basic string manipulation to make: MapAddress *.${domain} 127.0.0.1 And yes, as you may think, the list is huge that has to be on its own included conf file, and also prone to be outdated every time a new TLD is created. But it works, in a dumb and prone to mistakes, it works. Can this be done better? Not antivirus way of all is permitted, some known items are blocked. I would prefer all is blocked and some items are permitted. The real objective was to block all non .onion and .exit targets coming from a client, that the controller reports with SOURCE_ADDR, but I didn't find an option to MapAddress per client or anything similar to that do manipulate addresses per client source, so that is why I started doing this for all tor traffic, which is not what I really want, but controlling targets per client.

1 0

GSoC 2022 - Tor Weather: Improving the Tor Network
by Sarthik Gupta 19 Sep '22

19 Sep '22

Hello everyone, I’m Sarthik Gupta (irc: sarthikg), a recent grad from Punjab Engineering College, Chandigarh & currently working as a Software Engineer at Soroco. This summer, I’ll be working on GSoC Project: “Tor Weather: Improving the Tor Network” with my mentors GeKo & Silvia. I’m extremely excited to be a part of Tor and am interested in working on this project! Briefing about the project: As of now, if any relay disappears from the tor-network, no one will know. This causes the network to lose out on bandwidth from nodes which have been down for hours because no-one knew they were down. Tor-Weather aims at solving this by creating a notification service which relay operators can subscribe to in order to get various types of updates for their relays. The tor-weather service will offer a plethora of notifications options for the relays. These include, the node being down, running on EOL/Outdated version, losing a flag, ranking in top 20/50/100, etc. These notifications can be subscribed & customised by the relay operators to fit their needs using a web-frontend. A detailed proposal for this project is available at: <https://gitlab.torproject.org/sarthikg/tor-weather/-/wikis/Proposal> https://gitlab.torproject.org/sarthikg/tor-weather/-/wikis/Proposal. I plan to keep this wiki updated with the progress & design decisions taken throughout the development of the project. Suggestions are always welcomed! Please reach out to us in irc (#tor-dev) for any ideas, questions, or suggestions you might have. Thanks, Sarthik Gupta

1 5

Shortcuts to data-heavy parts of the bootstrapping process
by Holmes Wilson 07 Sep '22

07 Sep '22

I was just at an event with a slow (but reliable) network and Tor was not able to connect; the "Loading relay descriptors" step just took too long. At some point I got an error message that indicated that it was giving up but that I had enough information to connect to onion addresses. I can't reproduce the problem now on a normal network, and I just went through the Tor code looking for the error message I saw, but I couldn't find it. But I figured I'd ask here to see if anyone was familiar with shortcuts Tor can take in its connection process that safely save time and bandwidth on slow connections if the only thing I intend to use Tor for is connecting to onion addresses. Are there any steps in bootstrapping that can be skipped if I only care about making and receiving onion address connections? Holmes

2 2