- tor-dev - lists.torproject.org

Re: [tor-dev] [tor-relays] Did 'Sandbox 1' break Tor for anyone else on 0.4.5.6?
by William Kane 15 Mar '21

15 Mar '21

Hi Peter, >Would be great if you could get details about the failing call. I already thought of gathering said details by tracing the process, but did not want to risk my uptime statistics, which would inevitably happen if I had to restart the server and service over and over (I disabled tracing globally through the Yama LSM as a security measure, i.e. kernel.yama.ptrace_scope == 3) - recently I lost the guard flag multiple times, caused by some sort of attack that I already reported on this list (tor-relays) - someone kept creating a fuckton of circuits through my relay (averaging 90k per minute), thus causing tor to run out of memory / get oom-killed by the kernel before it could even step in and close the circuits - if it was even trying to, it would make sense for the DoS mitigation code to be active only for the first link in the circuit aka the guard, and my node simply being a middle-only relay, it got completely stomped by said attack. After somewhat mitigating this attack by tweaking MaxMemInQueues, creating a bigger swap file and tuning vm.swappiness, I regained the guard flag, but then the hypervisor my KVM box is running under experienced some issues and had to be rebooted - once again, I received no notice of that until the relay was already offline for a few days, causing me to lose the guard flag again. Seems like luck is just not on my side these days, or well, it's been weeks now. > You should simply see a Permission Denied if the capability is the problem. Here's a copy from stdout, only happening if Sandbox is set to 1.: Mar 15 20:15:20.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Mar 15 20:15:21.000 [warn] fstat() on directory /var/lib/tor_debug failed. Mar 15 20:15:21.000 [err] Can't create/check datadirectory /var/lib/tor_debug Mar 15 20:15:21.000 [err] Error initializing keys; exiting Running it as a privileged user does not change thing, so no permissions issue: Mar 15 20:17:24.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Mar 15 20:17:24.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't. Mar 15 20:17:25.000 [warn] fstat() on directory /var/lib/tor_debug failed. Mar 15 20:17:25.000 [err] Can't create/check datadirectory /var/lib/tor_debug Mar 15 20:17:25.000 [err] Error initializing keys; exiting I've traced down the origin of the fstat() call to this piece of code: https://github.com/torproject/tor/blob/master/src/lib/fs/dir.c#L158 However, looking at the code that establishes and populates seccomp rules, it seems like fstat and it's 64 bit counterpart are not subject to (parameter) filtering, i.e. seccomp_rule_add_0 is invoked with the parameter SCMP_ACT_ALLOW, reading the manpage for seccomp_rule_add(3) reveals: "The seccomp filter will have no effect on the thread calling the syscall if it matches the filter rule." References: https://github.com/torproject/tor/blob/master/src/lib/sandbox/sandbox.c#L148 https://github.com/torproject/tor/blob/master/src/lib/sandbox/sandbox.c#L15… https://man7.org/linux/man-pages/man3/seccomp_rule_add.3.html So, even though technically, seccomp should allow these syscalls to be invoked, no matter which parameters are passed, somehow enabling the whole sandbox subsystem still breaks fstat. We are getting into tor-dev@ territory here, so maybe someone who is more experienced with the code base could figure out why this is happening, I'm pretty good at C/C++ on Linux / Windows and all the shenanigans that come with it, but lack time to debug this further. I've added tor-dev(a)lists.torproject.org as a CC just in case. - William 2021-03-15 17:10 GMT, Peter Gerber <tor(a)arbitrary.ch>: > Hi William > > William Kane: >> Hi everyone, >> >> Ever since I upgraded to tor version 0.4.5.6, enabling tor's built-in >> seccomp sandbox completely breaks tor, i.e. it gets killed by the >> kernel on start for a seccomp violation (fstat(..)) - sandboxing >> worked fine on 0.4.4.6, my system configuration did not change between >> the updates. > > Tor itself usually fails with a Permission Denied error when a syscall > fails due to seccomp. So, this is rather odd. > >> I figured this was happening because I do not grant the >> CAP_DAC_READ_SEARCH capability, but I'm not so sure anymore if that's >> the reason. > > You should simply see a Permission Denied if the capability is the problem. > > Would be great if you could get details about the failing call. If > seccomp is involved, you should be able to get details like this: > > • install package auditd > • make sure auditd is running > • crash Tor > • find the syscall with `ausearch -ts recent -i` > > Peter >

1 0

Proposal 328: Make Relays Report When They Are Overloaded
by David Goulet 03 Mar '21

03 Mar '21

Greetings, Attached is a proposal from Mike Perry and I. Merge requsest is here: https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/22 Cheers! David -- uSxMMaJozH7GAo7qjzhVUm5FDynPYtBfOeZcLS88XeU=

7 12

Best way to reload config on Windows?
by Holmes Wilson 22 Feb '21

22 Feb '21

Hi everyone, We’re building a Ricochet-inspired chat app, and there are situations where we want to create a new hidden service URL. On macOS and Linux we can send a SIGHUP to make Tor reload its config. What’s the best way to do this on Windows? I found an old issue for this (https://gitlab.torproject.org/tpo/core/tor/-/issues/10052 <https://gitlab.torproject.org/tpo/core/tor/-/issues/10052>) but it looks like it never got addressed. Thoughts? Holmes

3 4

Proposal 330: Modernizing authority contact entries
by Nick Mathewson 10 Feb '21

10 Feb '21

(I'm using 330 for this proposal, since 329 is reserved for conflux.) ``` Filename: 330-authority-contact.md Title: Modernizing authority contact entries Author: Nick Mathewson Created: --- Status: Draft ``` This proposal suggests changes to interfaces used to describe a directory authority, to better support load balancing and denial-of-service resistance. (In an appendix, it also suggests an improvement to the description of authority identity keys, to avoid a deprecated cryptographic algorithm.) # Background There are, broadly, three good reasons to make a directory request to a Tor directory authority: - As a relay, to publish a new descriptor. - As another authority, to perform part of the voting and consensus protocol. - As a relay, to fetch a consensus or a set of (micro)descriptors. There are some more reasons that are OK-ish: - as a bandwidth authority or similar related tool running under the auspices of an authority. - as a metrics tool, to fetch directory information. - As a liveness checking tool, to make sure the authorities are running. There are also a number of bad reasons to make a directory request to a Tor directory authority. - As a client, to download directory information. (_Clients should instead use a directory guard, or a fallback directory if they don't know any directory information at all._) - As a tor-related application, to download directory information. (_Such applications should instead run a tor client, which can maintain an up-to-date directory much more efficiently._) Currently, Tor provides two mechanisms for downloading and uploading directory information: the DirPort, and the BeginDir command. A DirPort is an HTTP port on which directory information is served. The BeginDir command is a relay command that is used to send an HTTP stream directly over a Tor circuit. Historically, we used DirPort for all directory requests. Later, when we needed encrypted or anonymous directory requests, we moved to a "Begin-over-tor" approach, and then to BeginDir. We still use the DirPort directly, however, when relays are connecting to authorities to publish descriptors or download fresh directories. We also use it for voting. This proposal suggests that instead of having only a single DirPort, authorities should be able to expose a separate contact point for each supported interaction above. By separating these contact points, we can impose separate access controls and rate limits on each, to improve the robustness of the consensus voting process. Eventually, separate contact points will allow us do even more: we'll be able to have separate implementations for the upload and download components of the authorities, and keep the voting component mostly offline. # Adding contact points to authorities Currently, for each directory authority, we ship an authority entry. For example, the entry describing tor26 is: "tor26 orport=443 " "v3ident=14C131DFC5C6F93646BE72FA1401C02A8DF2E8B4 " "ipv6=[2001:858:2:2:aabb:0:563b:1526]:443 " "86.59.21.38:80 847B 1F85 0344 D787 6491 A548 92F9 0493 4E4E B85D", We extend these lines with optional contact point elements as follows: - `upload=http://IP:port/` A location to publish router descriptors. - `download=http://IP:port/` A location to use for caches when fetching router descriptors. - `vote=http://IP:port/` A location to use for authorities when voting. Each of these contact point elements can appear more than once. If it does, then it describes multiple valid contact points for a given purpose; implementations MAY use any of the contact point elements that they recognize for a given authority. Implementations SHOULD ignore url schemas that they do not recognize, and SHOULD ignore hostnames addresses that appear in the place of the IP elements above. (This will make it easier for us to extend these lists in the future.) If there is no contact point element for a given type, then implementations should fall back to using the main IPv4 addr:port, and/or the IPv6 addr:port if available. As an extra rule: If more than one authority lists the same upload point, then uploading a descriptor to that upload point counts as having uploaded it to all of those authorities. (This rule will allow multiple authorities to share an upload point in the future, if they decide to do so. We do not need a corresponding rules for voting or downloading, since every authority participates in voting directly, and since there is no notion of "downloading from each authority.") # Authority-side configuration We add a few flags to DirPort configuration, indicating what kind of requests are acceptable. - `no-voting` - `no-download` - `no-upload` These flags remove a given set of possible operations from a given DirPort. So for example, an authority might say: DirPort 9030 no-download no-upload DirPort 9040 no-voting no-upload DirPort 9050 no-voting no-download We can also allow "upload-only" as an alias for "no-voting no-download", and so on. Note that authorities would need to keep a legacy dirport around until all relays have upgraded. # Bridge authorities This proposal does not yet apply to bridge authorities, since neither clients nor bridges connect to bridge authorities over HTTP. A later proposal may add a schema that can be used to describe contacting to a bridge authority via BEGINDIR. # Example uses ## Example setup: Simple access control and balancing. Right now the essential functionality of authorities is sometimes blocked by getting too much load from directory downloads by non-relays. To address this we can proceed as follows. We can have each relay authority open four separate dirports: One for publishing, one for voting, one for downloading, and one legacy port. These can be rate-limited separately, and requests sent to the wrong port can be rejected. We could additionally prioritize voting, then uploads, then downloads. This could be done either within Tor, or with other IP shaping tools. ## Example setup: Full authority refactoring In the future, this system lets us get fancier with our authorities and how they are factored. For example, as in proposal 257, an authority could run upload services, voting, and download services all at separate locations. The authorities themselves would be the only ones that needed to use their voting protocol. The upload services (run on the behalf of authorities or groups of authorities) could receive descriptors and do initial testing on them before passing them on to the authorities. The authorities could then vote with one another, and push the resulting consensus and descriptors to the download services. This would make the download services primarily responsible for serving directory information, and have them take all the load. # Appendix: Cryptographic extensions to authority configuration The 'v3ident' element, and the relay identity fingerprint in authority configuration, are currently both given as SHA1 digests of RSA keys. SHA1 is currently deprecated: even though we're only relying on second-preimage resistance, we should migrate away. With that in mind, we're adding two more fields to the authority entries: - `ed25519-id=BASE64` The ed25519 identity of a the authority when it acts as a relay. - `v3ident-sha3-256=HEX` The SHA3-256 digest of the authority's v3 signing key. (We use base64 here for the ed25519 key since that's what we use elsewhere.)

1 0

Proposed changes to Tor long-term-support (LTS) policy
by Nick Mathewson 04 Feb '21

04 Feb '21

Hi, all! I've been working on a proposed change to Tor's LTS policies. I've run it by a few people already, and now I'm posting it here for wider comment. (summary: If we decide to do this, we will still be able to do LTS releases, but we will backport fewer things to them, and we will make fewer promises about how well they will work on the network.) ===================== # Background and summary: I'm proposing a change to Tor's long-term support (LTS) policies. For reference, our current policy is described at https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorRele… We've been struggling with our LTS policies for a while. In brief: we backport too many fixes, and we promise too much support for LTS releases. The developers don't like it, because the amount of things that we keep trying to fix in our LTS releases keeps us working on old crufty code for a long time. Many packagers don't like it, because they have a policy of auditing security backports, and we backport too much to our LTS releases for them to audit carefully. And our network maintenance group doesn't like it, because our commitment to supporting very old protocol versions keeps us from implementing performance and security improvements on a rapid schedule, unless we backport those changes to the LTS releases. Therefore, we're going to propose these changes: - That once a release becomes LTS-only, its code no longer gets anything but security patches (narrowly defined), and minimal patches to keep it working on the network. - We will no longer guarantee that an LTS-only release will work (or work well) on the mainline Tor network for its entire LTS lifetime. We'll try to deliver this if we can, but it won't be a definite guarantee. # In more detail We propose the following release statuses: - Development. (Every series starts out in this state as an alpha.) - Stable. (Once a series is officially 'ready', we call it stable.) - Old-stable. (Every supported stable release, except the most recent one, is in this state.) - Long-term support only. (Any LTS release, once a newer release has become old-stable. Only certain releases will get LTS support.) Every series starts out in "development". Once it's officially ready, we call it "stable". All stable releases besides the most recent one are "old-stable". Allowed in all releases: - Updates to authorities list - Updates to fallbackdirs list - Updates to geoip database LTS-only (any LTS release, once an newer release is oldstable): - Only two kinds of changes are allowed: - Security fixes, narrowly defined. (See below for a definition.) - _Simple_ patches that keep the release functional on the network. - Relays are not guaranteed to be supported on the network, although we'll try not to remove them gratuitously. - Clients and onion services are not guaranteed to work on the network, although we'll try not to break them gratuitously. In other words, with an LTS release there will be no guarantee that the software works on the network. The promise is that we will keep it working on the network when we can do so with simple low-risk patches, and that _if_ it works, we will fix security problems in it. Oldstable (All stable releases besides the most recent stable release): - Stability fixes are also allowed. - Relays will be supported on the network. - Clients and onion services will be supported on the network. - Dirauths may be supported. Stable (The single most recent stable release): - All fixes are allowed. - Relays will be supported on the network. - Clients and onion services will be supported on the network. - Dirauths will be supported. Development: - All fixes are allowed. - Relays will be supported on the network. - Clients and onion services will be supported on the network. - Dirauths will be supported. ============================== What is a security fix? - It is a _bugfix_ that resolves a vulnerability. _Features_ that make Tor more private, anonymous, or more secure won't count. ============================== The LTS policy above will apply to 0.3.5 _starting with 0.3.5.14_, since we've already made backports that will appear in 0.3.5.13. We have already committed to making 0.3.5 an LTS release until Feb 1, 2022. We also now commit to making 0.4.5 an LTS release until _at least_ Feb 15, 2023. Whether we continue to do this LTS for longer will depend on our experiences with this new policy. ============================== So, any proposed amendments to this? best wishes, -- Nick

1 0

(no subject)
by Jithin S 02 Feb '21

02 Feb '21

Hi, I have recently started running a TOR node with the nickname *CostlyOnion2. *At the time of writing of this email, the details of the node are as follows: *Uptime*: 14 days 3 hours 18 minutes and 0 second *Advertised Bandwidth*: 3.35 MiB/s *Flags*: *Fast Running Stable V2Dir Valid* *First Seen*: 2021-01-18 17:00:00 (14 days 19 hours 13 minutes and 32 seconds) *Last Restarted*: 2021-01-19 08:55:32 For current details, click here <https://metrics.torproject.org/rs.html#details/19EDB4798A4C170D603F86D8862B…> . My concern is how soon we will get a Guard status for our relay. I have read this <https://blog.torproject.org/lifecycle-new-relay> blog post regarding the life cycle of a relay. As it says, for a relay aged 8-68 days to get "Guard" status, we need to keep an eye on three factors *viz. *bandwidth, weighted fractional uptime, and time known. Suppose we keep running the relay all the time with the above-mentioned bandwidth(3.35 MiB/s), I would like to know about following - How long it will take to get the guard status? - My link bandwidth is quite high (close to 50MBytes/s), still the advertised is around 3.35MiB/s. What could be the possible factors for this? - As I am doing some analysis studies, we would also like to know what all factors we should take into account for the users to make use of our relay? I also request you to share any relevant resources for getting more information regarding the above questions, especially on the calculation of consensus weight. Thanks and regards, Jithin S

1 0

Relay stalling when creating circuits
by Andreas Kempe 24 Jan '21

24 Jan '21

Hello everyone! For a while now, I've noted that when running a non-exit relay under fairly heavy load that is allowed to be utilised as a client, it has a tendency to stall when trying to create new circuits. If the relay has not been used as a client for a while and has a need to create new circuits, CPU load shoots up to 100 % and the stalls for some amount of time. I've seen stalls of over 1 minute. I've taken two profiling traces of the relay, one during normal operations and during the stalling behaviour. This was done on version 0.4.4.6 and each profile is approximately a 10 second recording. Normal case: >- 84,34% event_base_loop > - 80,19% event_process_active_single_queue > - 42,87% scheduler_evt_callback > - 42,86% kist_scheduler_run > + 20,23% connection_handle_write > + 9,47% update_socket_info_impl > + 5,07% channel_flush_some_cells > + 2,49% smartlist_pqueue_pop > + 2,19% outbuf_table_add > + 1,06% smartlist_pqueue_add > + 28,38% conn_read_callback > - 5,27% periodic_event_dispatch > - 3,32% second_elapsed_callback > + 1,69% run_connection_housekeeping > + 0,98% circuit_build_needed_circs > + 1,73% save_state_callback > + 1,50% conn_write_callback > + 1,02% connection_ap_attach_pending > + 4,02% epoll_dispatch Stalling case: >- 86,27% event_base_loop > - 85,52% event_process_active_single_queue > - 31,78% periodic_event_dispatch > - 30,00% second_elapsed_callback > - 28,84% circuit_build_needed_circs > - 15,35% connection_ap_attach_pending > - 15,34% connection_ap_handshake_attach_circuit > - 15,34% circuit_get_open_circ_or_launch > 10,14% circuit_get_best > - 4,99% circuit_launch_by_extend_info > - 4,88% circuit_establish_circuit > + 2,11% router_choose_random_node > + 2,05% nodelist_add_node_and_family > 0,69% count_acceptable_nodes.isra.0 > + 13,39% circuit_launch_by_extend_info > + 0,80% run_connection_housekeeping > + 1,74% save_state_callback > - 30,76% connection_ap_attach_pending > - connection_ap_handshake_attach_circuit > - 30,74% circuit_get_open_circ_or_launch > - 30,63% circuit_get_best > 1,18% circuit_get_global_list > + 11,50% conn_read_callback > + 10,47% scheduler_evt_callback > - 10,47% scheduler_evt_callback > - kist_scheduler_run > + 6,27% connection_handle_write > + 1,54% channel_flush_some_cells > + 0,98% update_socket_info_impl > + 0,91% smartlist_pqueue_pop > 0,75% epoll_dispatch (The traces above are meant to be indented for legibility, but some mail clients think they know better.) Has anyone seen similar behaviour or have an inkling as to what's going on? I thought it best to ask before diving into the code. Cordially, Andreas Kempe

1 0

DirAuth usage and 503 try again later
by James 20 Jan '21

20 Jan '21

Good day. Is there any chance that torpy (https://github.com/torpyorg/torpy) was triggered this issue https://gitlab.torproject.org/tpo/core/tor/-/issues/33018 ? Some wary facts: - Torpy using old fashion consensus (not mircodesc) - When consensus not present in cache (first time usage) it downloads consensus from random directory authorities only. - Before August 2020 it was using plain HTTP requests to DirAuths. Now it creates "CREATE_FAST" circuits to DirAuths (is that right way by the way?) From other side: - Torpy store consensus on disk (so whenever client restart it must not download full consensus again) - It will try download consensus after time which sets by valid_time field from consensus which more than 1 hour (so it's not so often) - Torpy try get consensus by "diff" feature (so it's minimize traffic) Still may be some of this features not working well in some conditions. Which could cause a lot of consensus downloads in Jan 2020... Or may be you know more info about this situation? Do you have some recommendations for tor client implementation? Can you explain in several paragraphs what behavior of original tor client is? As far as I understand when first time original tor starts it tries download consensus from fallback dirs not from DA? Is this key point? There is one more issue https://gitlab.torproject.org/tpo/core/tor/-/issues/40239 which I'm not understand correctly. Let's imagine it's first run of tor client and that time coincidentally coincided with DA voting. That means client will not be able to download consensus? That is strange decision. Or do you mean clients must download consensus from fallback dirs which never in "voting" process?

4 6

torify/nmap results in SIGABRT
by Peng Yu 15 Jan '21

15 Jan '21

Hi, I see the following error. Is it a bug in torify/torsocks? Thanks. $ torify nmap -p7 google.com ... NSOCK ERROR [88.9380s] nsock_make_socket(): Socket trouble: Operation not permitted Assertion failed: (nse->iod->sd >= 0), function nsock_pool_add_event, file nsock_core.c, line 1273. Abort trap: 6 -- Regards, Peng

2 1

Has Core Tor Development Slowed? Or Are We Moving To Rust/arti?
by Neel Chauhan 09 Jan '21

09 Jan '21

Hi tor-dev@, I hope you all had a great holiday season. I noticed that Core Tor development, especially with the tor daemon, has slowed down significantly since the COVID crisis. Sorry if I have been less active in the Tor community as opposed to the past. I've been more focused on FreeBSD Ports as of now, but I still want to post at least the occasional Tor patch here and there. Core Tor/Tor hasn't seen an update since December 21, even when we are already a week into 2021. Is this related to the layoffs which happened last year? Or is Tor moving to Rust (via arti) and all the development is happening there? I'm guessing both. If it's the latter, I guess I have to start learning Rust sooner rather than later. Well, who am I kidding, I had to learn C# and PowerShell for my job (Disclaimer: I work at Microsoft, not on security or Windows/Azure however). Is there any other reason? Best, Neel Chauhan

3 2