- tor-dev - lists.torproject.org

Re: [tor-dev] The case for Tor-over-QUIC
by Ali Clark 12 Dec '21

12 Dec '21

Sections 3 and 6 of the Quux paper have some relevant discussion [1] > Unfortunately, it appears that the Quux QUIC paper studied QUIC at the > wrong position - between relays, and the QuTor implementation is > unclear. This means that it may still be an open question as to if > QUIC's congestion control algorithms will behave optimally in a > Tor-like network under heavy load. As Reardon and Goldberg noted in concluding remarks, approaches other than hop-by-hop will incur an extra cost for retransmissions, since these must be rerouted through a larger part of the network [RG09]. As Tschorsch and Scheuermann discuss [TS12], due to the longer RTT of TCP connections, end-to-end approaches will also take longer to “ramp up” through slow start and up to a steady state. Both of these factors (not to mention increased security risk of information leakage [DM09]) suggest that hop-by-hop designs are likely to yield beer results. In fact, the hop-by-hop approach may be viewed as an instance of the Split TCP Performance-Enhancing Proxy design, whereby arbitrary TCP connections are split in two to negate the issues noted above. > Unfortunately, the Quux implementation appears to use QUIC at a > suboptimal position -- they replace Tor's TLS connections with QUIC, > and use QUIC streams in place of Tor's circuit ID -- but only between > relays. This means that it does not benefit from QUIC's end-to-end > congestion control for the entire path of the circuit. Such a design > will not solve the queuing and associated OOM problems at Tor relays, > since relays would be unable to drop cells to signal backpressure to > endpoints. Drops will instead block every circuit on a connection > between relays, and even then, due to end-to-end reliability, relays > will still need to queue without bound, subject to Tor's current (and > inadequate) flow control. A fully QUIC relay path (with slight modication to fix a limit on internal buffer sizes) would allow end-to-end backpressure to be used from the client application TCP stream up to the exit TCP stream. Leaving aside Tor’s inbound rate limit mechanism but retaining the global outbound limit, this design would allow max-min fairness to be achieved in the network, as outlined by Tschorsch and Scheuermann [TS11]. ... Once implemented however, backpressure would allow Tor to adopt a signicantly improved internal design. In such a design, a Tor relay could read a single cell from one QUIC stream’s read buffer, onion crypt it, and immediately place it onto the write buffer of the next stream in the circuit. This process would be able to operate at the granularity of a single cell because the read and write operations for QUIC are very cheap user-space function calls and not syscalls as for host TCP. The schedule of this action would be governed by the existing EWMA scheduler for circuits that have both a readable stream and a writeable stream (and as allowed by a global outgoing token bucket), allowing optimal quality of service for circuits. It’s expected that backpressure implemented in this way will yield signicant performance and fairness gains on top of the performance improvement found in this thesis. One issue for Quux was that it used the Chromium demo QUIC server code as the basis for its implementation, which was fine for performance research but not such a good choice for Tor's networking stack. Several Rust implementations have been released with server-side (not just client-side) usage, so I expect that to be much less of an issue today. io_uring is also a significant development since Quux was developed, as it can reduce the performance hit for host-TCP syscalls, or for using recvmsg instead of recvmmsg with QUIC if the implementation makes it difficult to use recvmmsg on the listener side. [1] https://www.benthamsgaze.org/wp-content/uploads/2016/09/393617_Alastair_Cla… The following paper has in-depth discussion, but I don't have a copy to hand unfortunately: Ali Clark. Tor network performance — transport and flow control. Technical report, University College London, April 2016

1 0

Client identification for authenticated onions
by cho8jeiv4aus＠paperboats.net 12 Dec '21

12 Dec '21

Hi there. I had an idea recently for an onion service to improve the UX of sites that require a login. The site would have two onions: one for those who want to use onion auth and another for those who don't or are still setting it up. A user would first sign in with a username+password on the unauthenticated onion and click a button to generate a certificate associated with their account. Then they would add the public key to their browser and visit the authenticated onion. The application server would then match the pubkey used to authenticate with an account in the database, and log them in automatically. I've looked in the mailing list archives and `man 1 tor` but didn't find anything that would facilitate this. The closest, it seems, is HiddenServiceExportCircuitID, but that is for *circuit* IDs, not *client* IDs. Is this possible to implement, either as an operator or as a Tor developer? As an operator, an alternative would be to generate one (authenticated) onion service per user and route them all to the same place with different Host headers, but that seems rather inefficient, and I don't know how well the tor daemon scales up to hundreds of onion services anyway. P.S. I didn't find an easy way to do full text search on the mailing list archives, so I wrote a little script to download them all. I've attached it in case it ends up useful. It requires python3.8+ and you'll need to `pip install aiohttp anyio BeautifulSoup4` first. After that you can run `./pipermail_fetch.py https://lists.torproject.org/pipermail/tor-dev/` and then something like `rg --context 3 --search-zip '^[^>].*search term here'` will do the trick.

3 2

compiling torsocks
by lejeczek 12 Dec '21

12 Dec '21

Hi guys A complete non-dev/programmer here so please go easy on me. I'm trying to compile torsocks with 'mock', while 'tor' compiles okey for 'torsock' I fail with: ... configure.ac:20: comes from Automake 1.16.1. You should recreate configure.ac:20: aclocal.m4 with aclocal and run automake again. WARNING: 'automake-1.16' is probably too old. You should only need it if you modified 'Makefile.am' or 'configure.ac' or m4 files included by 'configure.ac'. The 'automake' program is part of the GNU Automake package: <http://www.gnu.org/software/automake> It also requires GNU Autoconf, GNU m4 and Perl in order to run: <http://www.gnu.org/software/autoconf> <http://www.gnu.org/software/m4/> <http://www.perl.org/> make[1]: *** [Makefile:600: Makefile.in] Error 63 make: *** [Makefile:466: all-recursive] Error 1 ... My setup is Centos 9 and obviously I do it with an rpm/spec. Would you guys be kind to guide me to troubleshoot this? many thanks, L.

1 0

Accessing Shared Random Values as a Protocol on top of Tor
by Sebastian Hoffmann 07 Dec '21

07 Dec '21

Hi, I'm wondering if I can access the shared random value[1] while developing a protocol/application on top of Tor onion services. The application is still in early development, but it would be great if I could depend on the shared random value. If this is not the correct mailing list for this question, I would be glad if you could point me to one. --Sebastian [1]: PUB-SHAREDRANDOM in https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt

2 1

proposal 328: consensus parameters
by nusenu 21 Nov '21

21 Nov '21

Hi, https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/328-re… > For DNS timeouts, the X and Y are consensus parameters > (overload_dns_timeout_scale_percent and overload_dns_timeout_period_secs) > defined in param-spec.txt. should one be able to find these parameters (overload_dns_timeout_scale_percent and overload_dns_timeout_period_secs) on https://consensus-health.torproject.org/#consensusparams or in https://collector.torproject.org/recent/relay-descriptors/consensuses/ or is this not yet deployed? What are the values of these parameters currently? thanks, nusenu -- https://nusenu.github.io

2 2

prometheus relay label
by nusenu 09 Nov '21

09 Nov '21

Hi, when adding MetricsPort support to ansible-relayor I realized that many operators that run more than one tor instance per server will run into an issue because tor's relay prometheus metrics has no identifying label like fingerprint= or similar to tell tor instances appart. The instance= default label can have the same value for all tor instances on a given server so that can not be used. To avoid using nickname (might not be set) the easiest option is probably to use the relay's SHA1 fingerprint or alternatively the IP:ORPort combination which is unique per server but not necessarily globally unique (RFC1918 IPs). Another neat option for operators is to use node_exporter's textfile collector to collect tor's MetricsPort content to avoid having to run an additional webserver for TLS and authentication (because unlike tor's exporter node_exporter comes with TLS and authentication builtin). In that case the suggested solution would be even more needed because in that case relabling via prometheus' scrape config is no longer possible. What do you think about this suggestion? kind regards, nusenu -- https://nusenu.github.io

1 0

A Simple Web of Trust for Tor Relay Operator IDs
by nusenu 05 Nov '21

05 Nov '21

Hi, I wrote down a spec for a simple web of trust for relay operator IDs: https://gitlab.torproject.org/nusenu/torspec/-/blob/simple-wot-for-relay-op… This is related to: https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/iss… https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html kind regards, nusenu -- https://nusenu.github.io

4 6

proposal 328 status
by nusenu 01 Nov '21

01 Nov '21

Hi, I'm wondering if the current version of the text is the latest available version of it or if there is somewhere a newer version that hasn't been pushed yet? https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/328-re… "Status: Draft" but it is already in released tor versions. also in the context of this change: https://gitlab.torproject.org/tpo/core/tor/-/issues/40364 the proposal still mentions extra-info documents. thanks, nusenu -- https://nusenu.github.io

2 3

Re: [tor-dev] [tor-relays] Relays running an unsupported (EOL) Tor version
by grarpamp 28 Oct '21

28 Oct '21

> mpan: >> Is there any data available that sheds light on >> why operators run outdated versions Besides latent OS packages, or being busy, or simply not updating things, those are natures of computing world anyway... or having no network operations crypto-monetization model as some nextgen p2p overlay-exit networks are now working with... there can be other reasons people may run different versions... tor the software is different from from Tor Project Inc. The software is opensource and BSD licensed. Thus anyone may copy, run, share, redistribute, fork, modify, support it, create and vote in any consensus, run relays, run more networks than just tor on their nodes, run services, etc, completely without involvement from, and indeed in full disregard of whatever Tor Project Inc and its people may say. The tor protocol, code, and operational network are not the property of Tor Project Inc, nor are its operators and users under its command and control. tor's users may run whichever of the many tor client implementations they wish to run, and may run whatever protocols, applications, and uses over the tor network that they wish. tor's relay operators and dirauths are free to run and support the running of older, different, forked, or project protocol addition enhancement or migration versions, in part in order to support features that some of the entire global userbase of tor are using, and have no good replacement for, or may wish to develop apps to, and run them upon or over, such features and capabilities in the future. Such as the censored topic of v2 onions with OnionCat, OnionVPN, etc in order to continue or design, deploy, and run new p2p apps comms, etc over those, ie... https://www.onioncat.org/ So a large number of relays may be freely and rightly choosing, as is their right if they wish, to continue running a v2 onion version for that. And overlay nets have some great uses, some examples of which Tor Project advertises, such that those users or even operators may prefer not to post, so you may want to consider some of those good uses for them in their stead, even ones that are dependent on such versions. And another topical fact re versions, which will be censored, is that attackers do falsify their version strings, and a lot more, in order to run whatever custom exploits they want against the network. And that Traffic Analysis and Sybil attacks nodes are real and in use. And that there is no longer sufficient warning and ongoing visibly posted education on these and other matters, in particular at point of download, install, splashpage, and frontpage... even some warnings were removed... versioned away. These are the sort of lack of info that can put users at severe risk. Tor Project Inc is censoring embarassing or simple facts / info. And is now attempting to silence and kill useful and in use features and future application possibilities based on them, whitewashing them with handwavy vague absolutist claims such as "old" or "insecure", instead of creating detailed comparisons for users. tor's users and operators are the ones who get to choose their own versions, and use appropriate features / freedom / security tradeoffs, not by the sole dictate of Tor Project Inc. Which by the way is funded to $Millions per year so that is not an argument to killing otherwise modularizable features either, but may be why there are insufficient disclaimers, and censors. On 10/28/21, Georg Koppen <gk(a)torproject.org> wrote: > I don't think we have [...] feedback Well when Tor's hypocrites, liars, and frauds are censoring feedback etc off all their "bricked up" fora, full stop. Thus their users and operators are missing information and topical discussions may hardly flourish can they in an environment of censor, chilled, and steered speech. The censorship of conversation on tor by Tor Project Inc and its people... while publicizing claims to cherish and uphold Free Speech ideals... is blatantly hypocritical, and it must end.

1 0

Arti report 8: October 14 through October 27
by Nick Mathewson 27 Oct '21

27 Oct '21

# Arti Report 7: October 14 through October 27 # Towards Arti 0.0.1 On Monday November 1, we're planning to put out Arti version 0.0.1. Our goal is to include all the features that are needed for reasonable security, and a top-level API that isn't _so_ far from completely wrong. Right now, it looks like we're in good shape for that timeline. Since the last update, we've fixed a lot of smaller issues, including: * running out of files on OSX * making it harder to accidentally leak DNS requests * lots of API refactoring * restored the ability for multiple Arti instances to share a single set of local directories * easier setup * easier API for stream isolatoin * more reliable tests for asynchronous timeout-based logic * and more! We're now working on documentation and usability. There's now an example program in [`crates/arti-client/examples`](https://gitlab.torproject.org/tpo/core/arti/-/blob/main/crates/arti-client/examples/hyper.rs) that uses [`hyper`](https://hyper.rs/) to download an HTTP document, and we're adding examples elsewhere in our top-level API documentation. # Followup from our guard implementation Our work on guards (completed in the last round) has kicked off a new batch of guard research. As with other parts of the Tor protocols, implementing our specification in Rust has exposed some weaknesses or confusing points in our design. In response to issues that we found, we've opened a few issues and written a couple of proposals to improve our code. For example, see: * [Proposal 336](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/3…, to randomize guard retry timing. * [Proposal 337](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/3…, to describe a simpler formulation of our guard behavior. * [torspec#67](https://gitlab.torproject.org/tpo/core/torspec/-/issues/67), to treat guards as usable more eagerly. * [torspec#68](https://gitlab.torproject.org/tpo/core/torspec/-/issues/68), to improve our behavior when our primary guards are down. # What's next Once the next release is out, we'll turn our attention to Arti 0.1.0. For that release, our priority target is beta testing and experimental embedding. We'll be working to improve performance and to stabilize a set of stable APIs to provide a wider set of functionality for applications that want to embed Arti in different scenarios. We'll need your help, though: we will need feedback from everybody who's interested in using our code, in order to make sure that we're providing solid, usable interfaces that do what you need. Please try it out, and let us know what's bad or missing! We're hoping to get Arti 0.1.0 released some time in March of 2022, with multiple smaller update releases between now and then. At our bi-weekly meeting next Wednesday, we'll be prioritizing tasks for the next set of releases, and refining our roadmap for the coming months. Why not join us? Information is on the [meeting pad](https://pad.riseup.net/p/arti-meeting-pad-keep). # Thanks! Thanks to Jani Monoses and Dimitris Apostolou for their patches in this release! And special thanks and welcome to eta, our new team member! She's started with Tor last Tuesday, and has hit the ground running, already fixing substantial bugs and refactoring a bunch of tricky code. It's great to watch the pace and quality of our development improve as more people join the team!

1 0