- tor-dev - lists.torproject.org

Interoperation with libp2p
by Mike Mestnik 07 Apr '22

07 Apr '22

https://gitlab.torproject.org/tpo/core/torspec/-/issues/64

5 5

[dappy] Willing to chat with tor devs, about name system issues/solutions
by Raphaël Fabre 27 Mar '22

27 Mar '22

Hello I'm Raphaël (fr) I just joined the tor dev mailing list. I would like to chat with tor developers, particularly if they have worked, or are interested in the issues regarding a name system for tor. I'm the lead developer of dappy https://dappy.tech , we'll launch in 2022 and I do think we have interesting properties, for the public web as well as for tor and privacy-focused web projects. We are the only name system in the world that does co-resolution, that's the way we found to maintain a consistent name system, and also avoid censorship and phishing. Our system has the following properties: - blockchain-based name system: it simply means that mapping is globally consistent, name management is distributed in the sense that a blockchain handles it, the resolver just connect to this blockchain. - Systematic co-resolution (not rotation): lookup request are always addressed to a network of independant agents: there are many instead of a single one. And then there is consensus at browser level. This prevents 90% of attacks or attempt of censorship/phishing. - Anonymous registrations - Load-balancing of names: you can attach 20 IP addresses to your name, dappy browser will try each one of them until it gets a response. - 100% encrypted/https Censorship cannot happen, neither at the storage location (blockchain) or on-the-fly at resolution time (co-resolution) We will launch in 2022 and would be thrilled to exchange with some developers or engineers. This document has lead me to the path of the tor-dev mailing list https://gitlab.torproject.org/legacy/trac/-/wikis/doc/OnionServiceNamingSys… Happy to chat Merry Christmas Raphaël Fabre Building a ultra-secure blockchain-based name system and browser https://dappy.tech

2 2

Time interval for changing Introduction Points in Tor Hidden Services
by Piyush Kumar Sharma 23 Mar '22

23 Mar '22

Hi all, I have been investigating the Tor hidden services for some research work. I am finding it hard to obtain information about how often do Introduction Points of hidden service change. More specifically, I am looking for answers to the following questions: 1.) If the tor relays selected as Introduction Points for a hidden service go down (e.g., due to DoS), then in what time duration does the hidden service select new Introduction Points automatically? 2.) Even when the Introduction Points are not down, is there a duration after which they are automatically changed by the hidden service? If so, what is this duration? I have already tried to find this information in the Tor-spec about onion v3 services. But could not find answers to these specific questions. Thus, it would be really helpful if someone can answer these questions or point to some resources where this information can be obtained. Thanks

2 3

Gosling onion-to-onion specifications
by Richard Pospesel 19 Mar '22

19 Mar '22

Hi tor-dev, As part of my work with Blueprint for Free Speech, I recently gave a short presentation during the 2021 state-of-the-onion where we announced Gosling ( see https://youtu.be/mNhIjtXuVzk?t=8155 ). If you missed the talk, the tldr; is that we're developing a specification and reference implementation library for building (onion service based) anonymous+private+secure peer-to-peer applications. Essentially, we're taking what we've learned about onion-to-onion authentication from Ricochet-Refresh, extracting and improving the relevant pieces, and packaging it all in a library that developers can use to build their own anonymous+private+secure peer-to-peer applications. Our hope is that future developers will not need to be tor experts to build these types of applications. Today ,I'm happy to announce that we just made the the gosling repo on Github public! - https://github.com/blueprint-freespeech/gosling Things are little bare-bones at the moment, but the most relevant piece right now is the protocol specification here: - https://github.com/blueprint-freespeech/gosling/blob/main/docs/protocol.md You'll also find some initial prototyping work under the source directory (the pace of development should pick up come 2022). Please go take a look and feel free to respond here with any questions, concerns, criticisms, etc. Thanks! best, -Richard

1 1

txtorcon v22.0.0
by meejah 16 Mar '22

16 Mar '22

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I'm pleased to announce txtorcon 22.0.0. This fixes some broken infrastructure. * Use GitHub Actions (not Travis) * Update method to upload coverage to coveralls You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/22.0.0 https://github.com/meejah/txtorcon/releases/tag/v22.0.0 Releases are also available from the hidden service: http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check 89a1b65e32a4b369d67e6c166387fbc468cc5d05227448d239a5e7e9718aa053 dist/txtorcon-22.0.0.tar.gz 824b5df1977bedabfc1c49c9523b8fa1b7cff11d6fee78015df1ce133685779c dist/txtorcon-22.0.0-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCgAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAmIyVzMRHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaaeNYQf/XBYfAvqqvT/jU+z8EUwgj0EJbFusNAls 8W37RE8fRkxTCYBOnfmK2IlQouHLBVgjzS2H0ZGyAzczxZb/kfY7uRbAm7N63eMx rc7urZtDeHS4K7+cUPf03KlqYdKmbIGEezPVQSNRT1/UZ/kTB6CxMqteyXxfYkvY +pkfIvOJ49Yw6KuMt+iWKRNnfVsMNYX+gV6PNYBHoWGRTWxANReaXRSowe+5Cgus 4O51I3+1QH1slLIH77Dvpktmqka+Fbs3mDWm1ICzf4rB0z+aJRxt7xYjNnhaLCPQ 5xeY1IdmmJAxg/WouMQh1Kus8eEWgIhFLeigPN+ABwt2VziL1lL8XQ== =HKmX -----END PGP SIGNATURE-----

1 0

Proposal 338: Use an 8-byte handshake in NETINFO cells
by Nick Mathewson 14 Mar '22

14 Mar '22

``` Filename: 338-netinfo-y2038.md Title: Use an 8-byte timestamp in NETINFO cells Author: Nick Mathewson Created: 2022-03-14 Status: Open ``` # Introduction Currently Tor relays use a 4-byte timestamp (in seconds since the Unix epoch) in their NETINFO cells. Notoriously, such a timestamp will overflow on 19 January 2038. Let's get ahead of the problem and squash this issue now, by expanding the timestamp to 8 bytes. (8 bytes worth of seconds will be long enough to outlast the Earth's sun.) # Proposed change I propose adding a new link protocol version. (The next one in sequence, as of this writing, is version 6.) I propose that we change the text of tor-spec section 4.5 from: ``` TIME (Timestamp) [4 bytes] ``` to ``` TIME (Timestamp) [4 or 8 bytes *] ``` and specify that this field is 4 bytes wide on link protocols 1-5, but 8 bytes wide on link protocols 6 and beyond. # Rejected alternatives Our protocol specifies that parties MUST ignore extra data at the end of cells. Therefore we _could_ add additional data at the end of the NETINFO cell, and use that to store the high 4 bytes of the timestamp without having to increase the link protocol version number. I propose that we don't do that: it's ugly. As another alternative, we could declare that parties must interpret the timestamp such that its high 4 bytes place it as close as possible to their current time. I'm rejecting this kludge because it would give confusing results in the too-common case where clients have their clocks mis-set to Jan 1, 1970. # Impacts on our implementations Arti won't be able to implement this change until it supports connection padding (as required by link protocol 5), which is currently planned for the next Arti milestone (1.0.0, scheduled for this fall). If we think that that's a problem, or if we want to have support for implementations without connection padding in the future, we should reconsider this plan so that connection padding support is independent from 8-byte timestamps. # Other timestamps in Tor I've done a cursory search of our protocols to see if we have any other instances of the Y2038 problem. There is a 4-byte timestamp in `cert-spec`, but that one is an unsigned integer counting _hours_ since the Unix epoch, which will keep it from wrapping around till 478756 C.E. (The rollover date of "10136 CE" reported in `cert-spec` is wrong, and seems to be based on the misapprehension that the counter is in *minutes*.) The v2 onion service protocol has 4-byte timestamps, but it is thoroughly deprecated and unsupported. I couldn't find any other 4-byte timestamps, but that is no guarantee: others should look for them too.

2 3

Fine Tunneling For Tor Network | Tor Browser
by Alessandro Greco 09 Mar '22

09 Mar '22

Dear Tor-Dev, My name is Alessandro Greco and I am an Italian computer science student, I am finishing my studies and therefore I am working with my thesis and, as a topic, my supervisor and I have chosen the Tor network. The work done focuses entirely on the Tor Browser torrc configuration file, which is why I wrote Professor Steven Murdoch and he pointed me to this method in order to get in touch with the current Tor-Project developers. I state that I am not good in English and therefore I may be wrong or not give the right weight to the words. Going into the matter, I have developed an extension currently available only on Firefox reachable via the addresshttps://addons.mozilla.org/it/firefox/addon/tropea-project/. The initial goal was to simplify the tunneling phase, already editable through the Tor Browser torrc file, through commands such as ExitNode or ExcludeNode and much more. In order to simplify the use, I decided to create an extension and an "advanced" section, thus bringing back user-friendly graphic interfaces already well known to average users (the advanced section consists of a web page), which would allow modify the file to your liking without necessarily having to follow correct syntax and without having to go too far into the technical aspect of Tor Browser. Why? I decided to simplify the use of this configuration file because I believe that the path of "simplification" is the only (or in general one of the most important) way to be able to expand the catchment area by trying to accommodate more people who have the need for a network like Tor in order to be able to divert dictatorial censorship methods by governments. I want to give a practical example, let's consider the current situation between Russia and Ukraine. Although Putin belongs to Russia, it is also true that there is a large slice of Russian citizens who are intellectually suppressed every day given the limits of censorship by the Russian government and by other governments that limit the people in order to weaken Putin. Russia has currently blocked several social networks so that citizens can no longer share the atrocities that are happening, so much so that Anonymous has asked to publish photos and videos of what is happening through Google Maps or other applications that are currently not censored. In all this mess, I sincerely think that Tor can significantly affect the protection of truth and rights on the net. But it is also true that many people do not know how to use or modify these settings correctly or, more simply, they may not even know that they can change some settings. I strongly believe that a breakthrough in the world of Tor Networks is needed and so that citizens of every state in the world can have, without minimum IT requirements, the ability to fully use Tor Browser and consequently Tor. The thesis work is called Tropea-Project (Tropea is a type of onion from our area, if you want to do a search, look for Tropea Onion on Google) and it is completely free and open-source so that anyone can dare to add new features. The features currently available are the following: [Add-Remove] EntryNodes + StrictNodes [Add-Remove] ExitNodes + StrictNodes [Add-Remove] ExcludeNodes [Add-Remove] ExcludeExitNodes [Edit] GeoIPExcludeUnknow [Edit] Reset configuration [Torify App] Torify /*It depends on the application launched, [Working Application](https://github.com/NoNameoN-A/Tropea-Project/blob/main)*/ Please consider this project, at the moment I am struggling with the writing of the thesis so in a few weeks an extremely detailed guide on the whole programming aspect will be published so that I can help any student, programmer, hacker and anyone who wants to improve existing features or add new ones. I am very excited to write you this email and I hope you can consider this development of mine which focuses 100% of the forces so that the Tor project can help free as many people as possible from inhuman web slavery. I believe that online freedom is a humanitarian right on par with education and water, so I think it is appropriate to develop new features that simplify its use. If you have read this far I would ask you now to see the demonstration video that I have published so that you can see for yourself what it does and I hope you can understand how much I care. Now more than ever anyone needs Tor. * Technical notes on the extension * In order for it to be used correctly, you must first start a local script called tropea.js, which is located in the socket-tropea folder of the Repository. The extension code is in the tropea folder of the Repository. Since the exact path of the Tor Browser folder is required, due to the configuration of the torrc file, it would be ideal to install it when installing Tor Browser so as to further simplify the whole process so that they don't even have to run the local script as it might launch when Tor Browser starts. Repository:https://github.com/NoNameoN-A/Tropea-Project Demonstration video:https://peertube.uno/w/acz9VzntwYFicwgxk7i9by I wrote an informal article on my blog:https://greco-alessandro.netlify.app/articles/tropea-project-la-rete-tor-da-un-altro-punto-di-vista/ Thesis with technical documentation of the code: At the moment not available because I haven't finished writing it yet. Best Regards, Alessandro Greco. -- FSF Member (NoNameoN), Join the Free Software Foundation! (fsf.org) Browse my WebSite! (autistici.org/nonameon)

1 0

Relay "Ping" Functionality
by Alexander Mages 19 Feb '22

19 Feb '22

Hello Tor-Dev, My name is Alex Mages, and I have been doing pluggable transport research with Eugene Vasserman (CC) at Kansas State University. Right now we're exploring latency-based attacks but are having trouble achieving a particular goal: a way to “ping” an arbitrary node in a client’s already-built (“live”) circuit. One-way timing is ideal but round trip time would suffice. We can glean this information during circuit construction, but what about a “live” circuit? Ideally, this would be a periodic thing Tor already keeps track of, but as an on-demand or as a byproduct/side-effect of a different function would also work. We have not been able to find a way to do this within the Tor (sub)protocol specs or the control port spec. Any ideas, suggestions, or criticisms would be greatly appreciated. Thanks, Alex Mages

3 4

onionoo overload_general_timestamp (prop 328)
by nusenu 10 Feb '22

10 Feb '22

Hi, in onionoo all timestamps used to be in the format YYYY-MM-DD hh:mm:ss Proposal 328 has timestamps in this same format https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/328-re… The newly added prop328 fields in oninoo appear to break with that convention https://metrics.torproject.org/onionoo.html#details_relay_overload_general_… Here is an example for an onionoo overload_general_timestamp which appears to be at millisecond granularity (the source has a granularity of an hour): 1636038000000 Was there a particular motivation for this format change and granularity? And what do you think about changing it to use the YYYY-MM-DD hh:mm:ss format for consistency and having a direct human readable format here as well? related: Karsten used to maintain onionoo protocol documentation/changelog and versions: https://metrics.torproject.org/onionoo.html#versions Is that and the 'version' field in onionoo no longer maintained? (since it didn't change with the new fields) kind regards, nusenu -- https://nusenu.github.io

2 3

onbasca - the next-generation bandwidth scanner
by Georg Koppen 10 Feb '22

10 Feb '22

Hello everyone! As many of you know we have been working on a simple bandwidth scanner (sbws) over the last years to deal with the old and unmaintained Torflow code on our bandwidth authorities. We learned a lot during that process, especially after we started to replace Torflow with the new sbws code on bandwidth authorities (today sbws is powering a majority of them, yay!). We realized that we needed to improve the robustness and testability of the code significantly, in particular as we want to build exciting features like loadbalancing capability on top of it and decided it would be easier to do so in a new tool: welcome onbasca. Onbasca takes the best out of sbws and makes the code easier to test and more robust for future improvements by deploying a database management system where we previously dealt with JSON files only.[1] The code repository lives in our network-health group[2] and is open for contributions. Get in touch in case you are interested, everyone is welcome! Georg [1] For a more detailed overview over the bandwidth scanner history, design issues we encountered in sbws, and decisions we made, see: https://tpo.pages.torproject.net/network-health/onbasca/history.html. [2] https://gitlab.torproject.org/tpo/network-health/onbasca

2 1

HAROI: Human Readable Authenticated Relay Operator Identifier
by nusenu 27 Dec '21

27 Dec '21

Hi, below is a partial proposal draft for human readable relay operator IDs that are authenticated by directory authorities. If there is any interest in implementing something like this I'll complete the draft and submit it via gitlab. kind regards, nusenu # HAROI: Human Readable Authenticated Relay Operator Identifier A HAROI is a DNS FQDN that can be chosen by a relay operator and linked to one or more relays in a verifiable way. The link is authenticated in the sense that it requires some control over the relay and the FQDN (on the DNS or webroot level). A relay can only be linked to a single HAROI. Relays publish their HAROI via their descriptor. Directory authorities verify the link and publish the verification result in their vote. ## Motivation Many tools in the tor ecosystem display at least some relay (operator) information (nickname, ContactInfo, ...), some examples are: - Tor Browser - Relay Search [1] - Onioncircuits by tails [2] - ExoneraTor [3] - allium [4] unfortunatelly there is no authenticated operator ID available, these tools could display, so they might display misleading information, something that has been exploited in the wild for impersonation attacks. There is a value in giving relay operators the possibility to declare an identifier that is globally unique, consistent and can not be easily spoofed by adversaries so they do not become easy victims of impersonation attacks. The tor ecosystem would benefit from an operator ID that can not be spoofed. This proposal is not replacing the relay ContactInfo. ## Design * A HAROI is optional and not mandatory. * A HAROI is verified by directory authorities in one of two ways, depending on the proof type. In the distant future where relays have no RSA1024 keys, Ed25519 proof types are added. * The used proof type can be selected by the relay operator. Successfully verified proofs are cached by directory authorities for 30 days. After 30 days proofs are verified again. Relay operators that want to make use of HAROI can participate without requiring a domain since many free services offer custom free subdomains (example: GitLab or GitHub pages). ## Proof Types Relay operators, that chose to set a HAROI, can select their preferred a proof type. ### uri-rsa This proof type can be verified by fetching the list of relay RSA SHA1 fingerprints from the FQDN via HTTPS using the well-known URI as defined in proposal 326 https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/326-to… Example: if the FQDN is example.com, the url to fetch the list of fingerprints is: https://example.com/.well-known/tor-relay/rsa-fingerprint.txt The TLS certificate used on the webserver must be from a trusted CA and logged in a public certificate transparency log. For N relays using the same FQDN only a single HTTPS GET request is needed. ### dns-rsa This proof type can be verified by performing DNS lookups. To make use of this proof type the DNS zone MUST be DNSSEC signed. The DNS query is constructed by combining the relay's fingerprint and the FQDN: relay-fingerprint.<FQDN> example: relay-fingerprint.example.com value: “we-run-this-tor-relay” relay-fingerprint is the 40 character RSA SHA1 fingerprint of the tor relay. Each relay has its own DNS record, a single TXT record MUST be returned per relay only. content of the TXT record MUST match: "we-run-this-tor-relay” Each relay requires a single DNS lookup (less scalable than the uri-rsa option). ## Relay Configuration Relay operators can specify their identifier via a torrc option. OperatorIdentifier <FQDN> <proof-type> example: OperatorIdentifier example.com dns-rsa ## Length Limit Although DNS FQDNs can be rather long, we limit HAROIs to 40 characters. (As of December 2021 the longest observed HAROI is 28 characters long.) Operators will not be able to specify a HAROI longer than 40 characters in their torrc. Directory authorities refuse to accept them as well. ## Relays Descriptor Changes This proposal defines a new optional descriptor field that is automatically verified and voted on by tor directory authorities. operatorid <FQDN> <proof-type> ## Directory Authorities Directory authorities refuse to accept domains on the public suffix list [5]. XXX TODO ## Security Considerations Relay operators can trick directory authorities into performing DNS lookups and HTTPS GETs on arbitrary domains. Possible solutions: Directory authorities could required PTR+A DNS records on the same domain as the given FQDN for the relays IP address. [1] https://metrics.torproject.org/rs.html [2] https://gitlab.tails.boum.org/tails/onioncircuits [3] https://metrics.torproject.org/exonerator.html [4] https://yui.cat/ [5] https://publicsuffix.org/list/public_suffix_list.dat -- https://nusenu.github.io

2 4

the consequences of deprecating debian alpha repos with every new major branch
by nusenu 21 Dec '21

21 Dec '21

Hi, tldr: - more outdated relays (that is a claim I'm making and you could easily proof me wrong by recreating the 0.3.3.x alpha repos and ship 0.3.3.7 in them and see how things evolve after a week or so) - more work for the tpo website maintainer - less happy relay operators [3][4] - more work for repo maintainers? (since a new repo needs to be created) When the tor 0.3.4 alpha repos (deb.torproject.org) first appeared on 2018-05-23 I was about to submit a PR for the website to include it in the sources.list generator [1] on tpo but didn't do it because I wanted to wait for a previous PR to be merged first. The outstanding PR got merged eventually (2018-06-28) but I still did not submit a PR to update the repo generator for 0.3.4.x nonetheless and here is why. Recently I was wondering why are there so many relays running tor version 0.3.3.5-rc? (see OrNetStats or Relay Search) (> 3.2% CW fraction) Then I realized that this was the last version the tor-experimental-0.3.3.x-* repos were shipping before they got abandoned due to the new 0.3.4.x-* repos (I can no longer verify it since they got removed by now). Peter made it clear in the past that the current way to have per-major-version debian alpha repos (i.e. tor-experimental-0.3.4.x-jessie) will not change [2]: > If you can't be bothered to change your sources.list once or twice a > year, then you probably should be running stable. but maybe someone else would be willing to invoke a "ln" commands everytime a new new alpha repo is born. tor-alpha-jessie -> tor-experimental-0.3.4.x-jessie once 0.3.5.x repos are created the link would point to tor-alpha-jessie -> tor-experimental-0.3.5.x-jessie It is my opinion that this will help reduce the amount of relays running outdated versions of tor. It will certainly avoid having to update the tpo website, which isn't a big task and could probably be automated but it isn't done currently. "..but that would cause relay operators to jump from i.e. 0.3.3.x to 0.3.4.x alphas (and break setups)!" Yes, and I think that is better than relays stuck on an older version because the former repo no longer exists and operators still can choose the old repos which will not jump to newer major versions. [1] https://www.torproject.org/docs/debian.html.en#ubuntu [2] https://trac.torproject.org/projects/tor/ticket/14997#comment:3 [3] https://lists.torproject.org/pipermail/tor-relays/2018-June/015549.html [4] https://trac.torproject.org/projects/tor/ticket/26474 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

4 7

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

Proposal 337: A simpler way to decide, "Is this guard usable?"
by Nick Mathewson 22 Oct '21

22 Oct '21

``` Filename: 337-simpler-guard-usability.md Title: A simpler way to decide, "Is this guard usable?" Author: Nick Mathewson Created: 2021-10-22 Status: Open ``` # Introduction The current `guard-spec` describes a mechanism for how to behave when our primary guards are unreachable, and we don't know which other guards are reachable. This proposal describes a simpler method, currently implemented in [Arti](https://gitlab.torproject.org/tpo/core/arti/). (Note that this method might not actually give different results: its only advantage is that it is much simpler to implement.) ## The task at hand For illustration, we'll assume that our primary guards are P1, P2, and P3, and our subsequent guards (in preference order) are G1, G2, G3, and so on. The status of each guard is Reachable (we think we can connect to it), Unreachable (we think it's down), or Unknown (we haven't tried it recently). The question becomes, "What should we do when P1, P2, and P3 are Unreachable, and G1, G2, ... are all Unknown"? In this circumstance, we _could_ say that we only build circuits to G1, wait for them to succeed or fail, and only try G2 if we see that the circuits to G1 have failed completely. But that delays in the case that G1 is down. Instead, the first time we get a circuit request, we try to build one circuit to G1. On the next circuit request, if the circuit to G1 isn't done yet, we launch a circuit to G2 instead. The next request (if the G1 and G2 circuits are still pending) goes to G3, and so on. But (here's the critical part!) we don't actually _use_ the circuit to G2 unless the circuit to G1 fails, and we don't actually _use_ the circuit to G3 unless the circuits to G1 and G2 both fail. This approach causes Tor clients to check the status of multiple possible guards in parallel, while not actually _using_ any guard until we're sure that all the guards we'd rather use are down. ## The current algorithm and its drawbacks For the current algorithm, see `guard-spec` section 4.9: circuits are exploratory if they are not using a primary guard. If such an exploratory circuit is `waiting_for_better_guard`, then we advance it (or not) depending on the status of all other _circuits_ using guards that we'd rather be using. In other words, the current algorithm is described in terms of actions to take with given circuits. For Arti (and for other modular Tor implementations), however, this algorithm is a bit of a pain: it introduces dependencies between the guard code and the circuit handling code, requiring each one to mess with the other. # Proposal I suggest that we describe an alternative algorithm for handing circuits to non-primary guards, to be used in preference to the current algorithm. Unlike the existing approach, it isolates the guard logic a bit better from the circuit logic. ## Handling exploratory circuits When all primary guards are Unreachable, we need to try non-primary guards. We select the first such guard (in preference order) that is neither Unreachable nor Pending. Whenever we give out such a guard, if the guard's status is Unknown, then we call that guard "Pending" until the attempt to use it succeeds or fails. We remember when the guard became Pending. > Aside: None of the above is a change from our existing specification. After completing a circuit, the implementation must check whether its guard is usable. A guard is usable according to these rules: Primary guards are always usable. Non-primary guards are usable for a given circuit if every guard earlier in the preference list is either unsuitable for that circuit (e.g. because of family restrictions), or marked as Unreachable, or has been pending for at least `{NONPRIMARY_GUARD_CONNECT_TIMEOUT}`. Non-primary guards are unusable for a given circuit if some guard earlier in the preference list is suitable for the circuit _and_ Reachable. Non-primary guards are unusable if they have not become usable after `{NONPRIMARY_GUARD_IDLE_TIMEOUT}` seconds. If a circuit's guard is neither usable nor unusable immediately, the circuit is not discarded; instead, it is kept (but not used) until it becomes usable or unusable. > I am not 100% sure whether this description produces the same behavior > as the current guard-spec, but it is simpler to describe, and has > proven to be simpler to implement. ## Implications for program design. (This entire section is implementation detail to explain why this is a simplification from the previous algorithm. It is for explanatory purposes only and is not part of the spec.) With this algorithm, we cut down the interaction between the guard code and the circuit code considerably, but we do not remove it entirely. Instead, there remains (in Arti terms) a pair of communication channels between the circuit manager and the guard manager: * Whenever a guard is given to the circuit manager, the circuit manager receives the write end of a single-use channel to report whether the guard has succeeded or failed. * Whenever a non-primary guard is given to the circuit manager, the circuit receives the read end of a single-use channel that will tell it whether the guard is usable or unusable. This channel doesn't report anything until the guard has one status or the other. With this design, the circuit manager never needs to look at the list of guards, and the guard manager never needs to look at the list of circuits. ## Subtleties concerning "guard success" Note that the above definitions of a Reachable guard depend on reporting when the _guard_ is successful or failed. This is not necessarily the same as reporting whether the _circuit_ is successful or failed. For example, a circuit that fails after the first hop does not necessarily indicate that there's anything wrong with the guard. Similarly, we can reasonably conclude that the guard is working (at least somewhat) as long as we have an open channel to it.

2 1

Proposal 336: Randomized schedule for guard retries
by Nick Mathewson 22 Oct '21

22 Oct '21

``` Filename: 336-randomize-guard-retries.md Title: Randomized schedule for guard retries Author: Nick Mathewson Created: 2021-10-22 Status: Open ``` # Introduction When we notice that a guard isn't working, we don't mark it as retriable until a certain interval has passed. Currently, these intervals are fixed, as described in the documentation for `GUARDS_RETRY_SCHED` in `guard-spec` appendix A.1. Here we propose using a randomized retry interval instead, based on the same decorrelated-jitter algorithm we use for directory retries. The upside of this approach is that it makes our behavior in the presence of an unreliable network a bit harder for an attacker to predict. It also means that if a guard goes down for a while, its clients will notice that it is up at staggered times, rather than probing it in lock-step. The downside of this approach is that we can, if we get unlucky enough, completely fail to notice that a preferred guard is online when we would otherwise have noticed sooner. Note that when a guard is marked retriable, it isn't necessarily retried immediately. Instead, its status is changed from "Unreachable" to "Unknown", which will cause it to get retried. For reference, our previous schedule was: ``` {param:PRIMARY_GUARDS_RETRY_SCHED} -- every 10 minutes for the first six hours, -- every 90 minutes for the next 90 hours, -- every 4 hours for the next 3 days, -- every 9 hours thereafter. {param:GUARDS_RETRY_SCHED} -- -- every hour for the first six hours, -- every 4 hours for the next 90 hours, -- every 18 hours for the next 3 days, -- every 36 hours thereafter. ``` # The new algorithm We re-use the decorrelated-jitter algorithm from `dir-spec` section 5.5. The specific formula used to compute the 'i+1'th delay is: ``` Delay_{i+1} = MIN(cap, random_between(lower_bound, upper_bound)) where upper_bound = MAX(lower_bound+1, Delay_i * 3) lower_bound = MAX(1, base_delay). ``` For primary guards, we set base_delay to 30 seconds and cap to 6 hours. For non-primary guards, we set base_delay to 10 minutes and cap to 36 hours. (These parameters were selected by simulating the results of using them until they looked "a bit more aggressive" than the current algorithm, but not too much.) The average behavior for the new primary schedule is: ``` First 1.0 hours: 10.14283 attempts. (Avg delay 4m 47.41s) First 6.0 hours: 19.02377 attempts. (Avg delay 15m 36.95s) First 96.0 hours: 56.11173 attempts. (Avg delay 1h 40m 3.13s) First 168.0 hours: 83.67091 attempts. (Avg delay 1h 58m 43.16s) Steady state: 2h 36m 44.63s between attempts. ``` The average behavior for the new non-primary schedule is: ``` First 1.0 hours: 3.08069 attempts. (Avg delay 14m 26.08s) First 6.0 hours: 8.1473 attempts. (Avg delay 35m 25.27s) First 96.0 hours: 22.57442 attempts. (Avg delay 3h 49m 32.16s) First 168.0 hours: 29.02873 attempts. (Avg delay 5h 27m 2.36s) Steady state: 11h 15m 28.47s between attempts. ```

2 1

Proposal 335: An authority-only design for MiddleOnly
by Nick Mathewson 17 Oct '21

17 Oct '21

``` Filename: 335-middle-only-redux.md Title: An authority-only design for MiddleOnly Author: Nick Mathewson Created: 2021-10-08 Status: Open ``` # Introduction This proposal describes an alternative design for a `MiddleOnly` flag. Instead of making changes at the client level, it adds a little increased complexity at the directory authority's voting process. In return for that complexity, this design will work without additional changes required from Tor clients. For additional motivation and discussion see proposal 334 by Neel Chauhan, and the related discussions on tor-dev. # Protocol changes ## Generating votes When voting for a relay with the `MiddleOnly` flag, an authority should set all flags indicating that a relay is unusable for a particular purpose, and against all flags indicating that the relay is usable for a particular position. These flags SHOULD be set in a vote whenever `MiddleOnly` is present, and only when the authority is configured to vote on the `BadExit` flag. * `BadExit` These flags SHOULD be cleared in a vote whenever `MiddleOnly` is present. * `Exit` * `Guard` * `HSDir` * `V2Dir` ## Computing a consensus This proposal will introduce a new consensus method (probably 32). Whenever computing a consensus using that consensus method or later, authorities post-process the set of flags that appear in the consensus after flag voting takes place, by applying the same rule as above. That is, with this consensus method, the authorities first compute the presence or absence of each flag on each relay as usual. Then, if the `MiddleOnly` flag is present, the authorities set `BadExit`, and clear `Exit`, `Guard`, `HSDir`, and `V2Dir`. # Configuring authorities We'll need a means for configuring which relays will receive this flag. For now, we'll just reuse the same mechanism as `AuthDirReject` and `AuthDirBadExit`: a set of torrc configuration lines listing relays by address. We'll call this `AuthDirMiddleOnly`. We'll also add an `AuthDirListsMiddleOnly` option to turn on or off voting on this option at all. # Notes on safety and migration Under this design, the MiddleOnly option becomes useful immediately, since authorities that use it will stop voting for certain additional options for MiddleOnly relays without waiting for the other authorities. We don't need to worry about a single authority setting MiddleOnly unilaterally for all relays, since the MiddleOnly flag will have no special effect until most authorities have upgraded to the new consensus method.

3 2