- tor-dev - lists.torproject.org

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

17 Dec '22

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

2 1

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

06 Dec '22

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

1 0

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

09 Nov '22

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

2 1

Release new version of stem
by Hefee 03 Oct '22

03 Oct '22

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

5 8

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

21 Sep '22

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

1 0

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

19 Sep '22

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

1 5

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

07 Sep '22

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

2 2

Introducing a Conjure PT for Tor
by Cecylia Bocovich 31 Aug '22

31 Aug '22

Conjure[0] is an anti-censorship tool in the refraction networking (a.k.a. decoy routing) lineage of circumvention systems. The key innovation of Conjure is to turn the unused IP address space of deploying ISPs into a large pool of "phantom" proxies that users appear to connect to. Due to the size of unused IPv6 address space and the potential for collateral damage against real websites hosted by the deploying ISPs, Conjure provides a possible solution to the problem of censors enumerating and blocking deployed bridges or proxies. I've been working with Jack Wampler and Eric Wustrow at the University of Colorado to implement a Conjure PT for Tor that uses the existing deployed Conjure stations[1]. # How it works Conjure clients first perform a registration step with the Conjure station to negotiate a phantom IP address to connect through. The idea of a registration phase that precedes the proxied connection is common among anti-censorship tools, including Snowflake. Like Snowflake, there are a few options for making the registration process censorship-resistant. Conjure currently offers unidirectional registration via Tapdance[2] decoy routing, and bidirectional registration via domain fronting. Once the client and station have negotiated a phantom IP address, the client makes a connection to the phantom address. The Conjure station sees this connection and instead proxies traffic using the haproxy[3] protocol to a client-specified destination. Conjure currently supports 3 different transport options for the connection between the client and the phantom proxy: a minimal SSH-based transport, obfs4, and webrtc. The Tor conjure pluggable transport[4] uses the gotapdance library[5] to register and connect to the production Conjure station through the negotiated phantom IP address. We have a deployed Tor bridge (named Haunt) that accepts haproxy connections from an allowlist of known Conjure stations. You can see details and usage metrics on Relay Search: https://metrics.torproject.org/rs.html#details/A84C946BF4E14E63A3C92E140532… # Next steps This PT is currently in development and only recommended for testing. We still have some work to do before the Tor Conjure PT can be rolled out to a large user base. The PT in its current form is very minimal in its features. We're reaching out to the development community now for initial feedback and testing. We are planning a slow ramp of client traffic to avoid placing stress on the stations and improve the reliability and censorship resistance of our setup. Immediate planned work includes: - securing the haproxy connection between the Conjure station and the bridge - making the registration connection censorship resistant - ongoing testing and development of the obfs4 transport integration - usability improvements and resilience in the event of overloaded Conjure stations - reproducible builds for Tor Browser For more details, check out the issue tracker for this project[6]. We have a milestone for shipping conjure support in alpha version of Tor Browser[7], which is the next major step in the rollout process. # Try it out yourself Instructions for cloning and building this PT are in the repository[4]. In the client/ directory there are two provided torrc files. For testing the production Conjure deployment, you may use the one named `torrc`. The other file, `torrc-testing` is for use with the libvirt-based testing and development environment[8]. Successful bootstrapping can take a few tries due to high load at the station. More detailed log messages will be written out to a log file conjure.log by default. This can be changed by modifying the -log argument in the ClientTransportPlugin line of the torrc file. If the station is overloaded, you will see a message like the following in conjure.log: ``` [11:32:12] [1-d9b572] failed to dial phantom [scrubbed]: dial tcp [scrubbed]: i/o timeout ``` Please try it out, open issues, ask questions, provide feedback! # Thanks! Thanks again to Jack and Eric for their efforts on this project, and to whole team of Conjure researchers, developers, and admins for their work on deploying Conjure and making it available for use. [0] https://censorbib.nymity.ch/pdf/Frolov2019b.pdf [1] https://censorbib.nymity.ch/pdf/Frolov2017a.pdf [2] https://censorbib.nymity.ch/pdf/Wustrow2014a.pdf [3] https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt [4] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… [5] https://github.com/refraction-networking/gotapdance [6] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… [7] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… [8] https://gitlab.torproject.org/cohosh/phantombox

1 0

Counting HS descriptor uploads
by Michael Rogers 17 Aug '22

17 Aug '22

Hi, The Briar team is working on a new app that uses Tor hidden services, and we're trying to work out when the server publishing a hidden service should consider the service to be reachable by clients. We've tried counting HS descriptor uploads via control port events, but we found that when republishing a hidden service that has been published before, the number of descriptor uploads seems to vary. When republishing a hidden service, is it guaranteed that at least one copy of the descriptor will be uploaded? Or are there circumstances where Tor might decide that enough copies were previously uploaded, and still contain up-to-date information about introduction points etc, so no new copies need to be uploaded? Thanks, Michael

3 3

TOR socket for P2P in Python
by Martin Neuenhofen 16 Aug '22

16 Aug '22

Dear Tor Developers, in my application, a client connects to a server via: *client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)client_socket.connect(ip,port)* I want to replace these two lines to create a client_socket whose IP address cannot be seen by the server. The application is e-polling. I looked into - torpy (too many timeouts), - socks (requires too much external configuration), - and I have tor installed (unknown how to use from within python). I just need a replacement for the two-liner code above. *The ideal solution:* is device & OS agnostic, portable, uses no peripherals or configuration (i.e., just one pip package to install), and works reliably. Thus, the below torpy solution would have been ideal if it had worked reliably: *from torpy import TorClient # pip install torpy* *class Torsocket:* * def __init__(self,ip,port): self.mgr1 = TorClient() self.tor = type(self.mgr1).__enter__(self.mgr1) self.mgr2 = self.tor.create_circuit(3) self.circuit = type(self.mgr2).__enter__(self.mgr2) self.mgr3 = self.circuit.create_stream((ip,port)) self.socket = type(self.mgr3).__enter__(self.mgr3) def send(self,data): self.socket.send(data) def recv(self,size): return self.socket.recv(size) def __del__(self): for bla in [self.mgr3,self.mgr2,self.mgr1]: type(bla).__exit__(bla, None, None, None)* It replaces the two-liner from the beginning with the below one-liner *client_socket = Torsocket(*server_data.server_address)* My questions/requests: - Is torpy connected to the real tor network (or is it a little toy twin)? If it is the real tor network then I will close this issue and open another one. - Are practical solutions available to my problem already?, and which of them works best for user-friendliness? - Can a pip package for a torsocket be made, as described above? i.e., something like torpy, but connecting to the real network? - Can I offer anything so that the ideal solution would be crafted and packaged?* *) If it helps, I could tell a lot about my project and how I believe it is significant and will be for the greater good of people. It is a fully implemented 1000LOC LSAG+WOT decentral P2P e-polling program with GUI that shall return trust and sovereignty into the people's hands. The only missing bit is a reliable tor connection.

2 3

bridge:// URI and QR codes
by meskio 10 Aug '22

10 Aug '22

Hello, We have a messy situation to share bridges between devices. BridgeDB and Tor Browser have QR codes but they use different format for them. There has being some attempts to standarize a bridge URI[0][1], but it looks like we never finished that work. Pier has produced an RFC of a bridge URI proposal: https://gitlab.torproject.org/tpo/applications/team/-/wikis/Design-Document… If you have an application that uses (or plan to use) bridge URIs or QR codes I'm interested on your take on that proposal. Do your application already have any kind of support for bridge URIs or QR codes? If so how do they look like? Will it break things if we change them? What do you think of the proposal? How can we improve it? Thank you. [0] https://gitlab.torproject.org/legacy/trac/-/issues/15035 [1] https://gitlab.torproject.org/tpo/applications/fenix/-/issues/40189 -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

5 8

Proposal 341: A better algorithm for out-of-sockets eviction
by Nick Mathewson 27 Jul '22

27 Jul '22

``` Filename: 341-better-oos.md Title: A better algorithm for out-of-sockets eviction Author: Nick Mathewson Created: 25 July 2022 Status: Open ``` # Introduction Our existing algorithm for handling an out-of-sockets condition needs improvement. It only handles sockets used for OR connections, and prioritizes those with more circuits. Because of these weaknesses, the algorithm is trivial to circumvent, and it's disabled by default with `DisableOOSCheck`. Here we propose a new algorithm for choosing which connections to close when we're out of sockets. In summary, the new algorithm works by deciding which kinds of connections we have "too many" of, and then by closing excess connections of each kind. The algorithm for selecting connections of each kind is different. # Intuitions behind the algorithm below We want to keep a healthy mix of connections running; favoring one kind of connection over another gives the attacker a fine way to starve the disfavored connections by making a bunch of the favored kind. The correct mix of connections depends on the type of service we are providing. Everywhere _except_ authorities, for example, inbound directory connections are perfectly fine to close, since nothing in our protocol actually generates them. In general, we would prefer to close DirPort connections, then Exit connections, then OR connections. The priority with which to close connections is different depending on the connection type. "Age of connection" or "number of circuits" may be a fine metric for how truly used an OR connection is, but for a DirPort connection, high age is suspicious. # The algorithm Define a "candidate" connection as one that has a socket, and is either an exit stream, an _inbound_ directory stream, or an OR connection. (Note that OR connections can be from clients, relays, or bridges. Note that ordinary relays should not get directory streams that use sockets, since clients always use `BEGIN_DIR` to create tunneled directory streams.) In all of the following, treat subtraction as saturating at zero. In other words, when you see "A - B" below, read it as "MAX(A-B, 0)". ## Phase 1: Deciding how many connections to close When we are find that we are low on sockets, we pick a number of sockets that we want to close according to our existing algorithm. (That is, we try to close 1/4 of our maximum sockets if we have reached our upper limit, or 1/10 of our maximum sockets if we have encountered a failure from socket(2).) Call this `N_CLOSE`. Then we decide which sockets to target based on this algorithm. 1. Consider the total number of sockets used for exit streams (`N_EXIT`), the total number used for _inbound_ directory streams (`N_DIR`), and the total number used for OR connections (`N_OR`). (In these calculations, we exclude connections that are already marked to be closed.) Call the total `N_CONN = N_DIR + N_OR + N_EXIT`. Define `N_RETAIN = N_CONN - N_CLOSE`. 2. Compute how many connections of each type are "in excess". First, calculate our target proportions: * If we are an authority, let `T_DIR` = 1. Otherwise set `T_DIR = 0.1`. * If we are an exit or we are running an onion service, let `T_EXIT = 2`. Otherwise let `T_EXIT = 0.1`. * Let `T_OR` = 1. > TODO: Should those numbers be consensus parameters? These numbers define the relative proportions of connections that we would be willing to retain retain in our final mix. Compute a number of _excess_ connections of each type by calculating. ``` T_TOTAL = T_OR + T_DIR + T_EXIT. EXCESS_DIR = N_DIR - N_RETAIN * (T_DIR / T_TOTAL) EXCESS_EXIT = N_EXIT - N_RETAIN * (T_EXIT / T_TOTAL) EXCESS_OR = N_OR - N_RETAIN * (T_OR / T_TOTAL) ``` 3. Finally, divide N_CLOSE among the different types of excess connections, assigning first to excess directory connections, then excess exit connections, and finally to excess OR connections. ``` CLOSE_DIR = MIN(EXCESS_DIR, N_CLOSE) N_CLOSE := N_CLOSE - CLOSE_DIR CLOSE_EXIT = MIN(EXCESS_EXIT, N_CLOSE) N_CLOSE := N_CLOSE - CLOSE_EXIT CLOSE_OR = MIN(EXCESS_OR, N_CLOSE) ``` We will try to close `CLOSE_DIR` directory connections, `CLOSE_EXIT` exit connections, and `CLOSE_OR` OR connections. ## Phase 2: Closing directory connections We want to close a certain number of directory connections. To select our targets, we sort first by the number of directory connections from a similar address (see "similar address" below) and then by their age, preferring to close the oldest ones first. > This approach defeats "many requests from the same address" and "Open > a connection and hold it open, and do so from many addresses". It > doesn't do such a great job with defeating "open and close frequently > and do so on many addresses." > Note that fallback directories do not typically use sockets for > handling directory connections: theirs are usually created with > BEGIN_DIR. ## Phase 3: Closing exit connections. We want to close a certain number of exit connections. To do this, we pick an exit connection at random, then close its circuit _along with all the other exit connections on the same circuit_. Then we repeat until we have closed at least our target number of exit connections. > This approach probabilistically favors closing circuits with a large > number of sockets open, regardless of how long those sockets have been > open. This defeats the easiest way of opening a large number of exit > streams ("open them all on once circuit") without making the > counter-approach ("open each exit stream on a its own circuit") much > more attractive. ## Phase 3: Closing OR connections. We want to close a certain number of OR connections, to clients, bridges, or relays. To do this, we first close OR connections with zero circuits. Then we close all OR connections but the most recent 2 from each "similar address". Then we close OR connections at random from among those _not_ to a recognized relay in the latest directory. Finally, we close OR connections at random. > We used to unconditionally prefer to close connections with fewer > circuits. That's trivial for an adversary to circumvent, though: they > can just open a bunch of circuits on their bogus OR connections, and > force us to preferentially close circuits from real clients, bridges, > and relays. > Note that some connections that seem like client connections ("not > from relays in the latest directory") are actually those created by > bridges. ## What is "A similar address"? We define two connections as having a similar address if they are in the same IPv4 /30, or if they are in the same IPv6 /90. # Acknowledgments This proposal was inspired by a set of [OOS improvements](https://gitlab.torproject.org/tpo/core/tor/-/issues/32794 ) from `starlight`.

2 1

Shrink Tor binary size
by Sergey Ponomarev 17 Jul '22

17 Jul '22

I’m working on a firmware for routers based on OpenWrt and it needs Tor out of the box for NAT punching i.e. SSH and Web admin access. It will expose a Single Onion Service i.e. not "hidden" with just 3 hop for a better performance. In fact it just needs to connect to some random relay to have a tunnel and encrypt/decrypt traffic. The full hidden service functionality with IP/RP dances is not needed: I'm not trying to hide the location of the router. In fact most users even don't need anonymity with the 3 hop to access their router but Tor requires 3. So this is probably a kind of abuse of the Tor network but this is the only free network of proxies. At the same time a user will have an encryption while accessing the router's admin panel. I may enable HTTPS with a self signed cert but users must accept it manually which is hard for inexperienced users. The Tor is already ported to OpenWrt but its binary is more than 2mb. For 16mb routers this is not critical but a lot and I need to keep space. So is it possible to compile Tor without some features? As far as I understood from autoconf I can disable Relay functionality. But maybe I can also disable some admin api parts and SOCKS proxy. Also OpenWrt out of the box has WolfSSL so is it possible to compile tor with it instead of OpenSSL? Another problem is files sizes inside of /var/lib/tor/: 20,442 cached-certs 2,303,443 cached-microdesc-consensus 8,725,598 cached-microdescs.new 3,531 state I think that all these files may be minimized. E.g. cached-certs contains keys in PEM format which is just Base64 form of DER. So switching to plain DER certs can significantly reduce size. As a side question: is it possible to make a small relay proxy that can work part time when I sleep? Imagine that each router already has a Tor. This is potentially thousands of relay nodes and all of them have a motivation to support the network which they are using themselves. But users don’t want to lose bandwidth. I see that I can set some traffic or bandwidth limits. But maybe I can write some script that will enable or disable the relay by schedule in the evening. As far I know relays must be always online so this will make the relay unstable and it won’t be used by Tor. Is it technically possible? Regards, Sergey Ponomarev, stokito.com

2 1

Want to build circuit via unpublished relay, can't add microdesc using control port
by ValdikSS 11 Jul '22

11 Jul '22

Hello everyone. I'm experimenting with Tor network and wanted to build a circuit via unpublished relay (PublishServerDescriptor 0). To do so, I set up a relay, got its authority descriptor, imported it with +POSTDESCRIPTOR in the client using control port and tried to build a circuit using its fingerprint with EXTENDCIRCUIT. Everything works fine with UseMicrodescriptors 0, however with MicroDescriptors activated, the client does not detect imported (full) descriptor, returning: 552 No descriptor for "fingerprint here" I found no way to import microdescriptor using control port and no other means to use unpublished nodes. How can I add microdesc which is not in consensus into router? Or how can I build circuit with a relay not in consensus otherwise?

3 2

Tor can't read HiddenServicePort unix socket through group permissions when starting as root and using setgid?
by keyandthegate 06 Jul '22

06 Jul '22

Permissions are set so tor should be able to access through the `postfix-test-queue` user: > $ sudo ls -l /var/spool/postfix-test/public/smtpd > srw-rw-rw- 1 postfix-test postfix-test 0 █████ /var/spool/postfix-test/public/smtpd > $ sudo ls -l /var/spool/postfix-test > # ... > drwx--x--- 2 postfix-test postfix-test-queue 4096 █████ public > $ sudo -u _tor-test id > uid=130(_tor-test) gid=141(_tor-test) groups=141(_tor-test),1006(postfix-test-queue) > $ cat /etc/tor/instances/test/torrc | grep HiddenServicePort > HiddenServicePort 25 unix:/var/spool/postfix-test/public/smtpd > $ cat /run/tor-instances/test.defaults | grep User > User _tor-test Running `tor@test` via the default systemctl config shows: > $ ps -ax -o uid,gid,supgid,command | grep /usr/bin/tor > 130 141 141 /usr/bin/tor --defaults-torrc /run/tor-instances/test.defaults -f /etc/tor/instances/test/torrc Which is missing the `postfix-test-queue` `1006` user which, for example shows up if I do: > $ sudo -u _tor-test sleep 1000 & ps -ax -o uid,gid,supgid,command | grep sleep > [1] 132314 > 0 141 141,1006 sudo -u _tor-test sleep 1000 Connecting using `sudo -u` works (the message indicates successful connection): > $ sudo -u _tor-test curl --unix-socket /var/spool/postfix-test/public/smtpd http://localhost > curl: (1) Received HTTP/0.9 when not allowed But connecting via tor does not: > $ torsocks --ipv6 curl http://█████.onion:25 > █████ ERROR torsocks[134873]: Host unreachable (in socks5_recv_connect_reply() at socks5.c:539) > curl: (7) Couldn't connect to server But does if I allow access to the socket to everyone: > $ sudo chmod "o+x" /var/spool/postfix-test/public/ > $ torsocks --ipv6 curl http://█████.onion:25 > curl: (1) Received HTTP/0.9 when not allowed Tor's relevant source code: [Tor: lib/process/setuid.c Source File](https://tpo.pages.torproject.net/core/doc/tor/setuid_8c_source.html)

1 1

Bootstrapping with a very inaccurate clock
by Michael Rogers 28 Jun '22

28 Jun '22

Hello again, Apologies for starting two threads in quick succession. First of all I want to say thank you for all the improvements in handling clock skew between 0.3.5 and 0.4.5. We recently migrated Briar to 0.4.5, and some situations that are common on mobile, such as the system clock being configured with the wrong timezone, are now much less likely to affect Tor connectivity (except when using obfs4). When the system clock is very far behind real time, Tor's clock skew events enable us to warn the user to check their time and date settings. When the clock is ahead of real time by up to a day, there are no clock skew events but Tor can bootstrap. But when the clock is several days ahead of real time, there are no clock skew events and Tor gets stuck boostrapping at 14%. At the moment we're having trouble distinguishing this situation from other situations that might cause bootstrapping to get stuck, such as access to the Tor network being blocked. So ideally we'd like to be able to detect that the clock is the problem and ask the user to fix it. I should say that this is probably a rare situation. Old devices that haven't been turned on for a while sometimes reset their clocks to a point in the distant past, but I've never seen a device spontaneously change its clock to a point in the distant future. Still, people do mess around with the time and date settings so we'd like to detect and fix this issue if possible. Is there any way for Tor to tell, during bootstrapping, that the system clock appears to be far ahead of real time? Thanks, Michael

1 0

Metrics: Estimating fraction of reported directory-request statistics
by David Fifield 27 Jun '22

27 Jun '22

I am trying to reproduce the "frac" computation from the Reproducible Metrics instructions: https://metrics.torproject.org/reproducible-metrics.html#relay-users Which is also Section 3 in the tech report on counting bridge users: https://research.torproject.org/techreports/counting-daily-bridge-users-201… h(R^H) * n(H) + h(H) * n(R\H) frac = ----------------------------- h(H) * n(N) My minor goal is to reproduce the "frac" column from the Metrics web site (which I assume is the same as the frac above, expressed as a percentage): https://metrics.torproject.org/userstats-relay-country.csv?start=2022-04-01… date,country,users,lower,upper,frac 2022-04-01,,2262557,,,92 2022-04-02,,2181639,,,92 2022-04-03,,2179544,,,93 2022-04-04,,2350360,,,93 2022-04-05,,2388772,,,93 2022-04-06,,2356170,,,93 2022-04-07,,2323184,,,93 2022-04-08,,2310170,,,91 I'm having trouble with the computation of n(R\H) and h(R∧H). I understand that R is the subset of relays that report directory request counts (i.e. that have dirreq-stats-end in their extra-info descriptors) and H is the subset of relays that report directory request byte counts (i.e. that have dirreq-write-history in their extra-info descriptors). R and H partially overlap: there are relays that are in R but not H, others that are in H but not R, and others that are in both. The computations depend on some values that are directly from descriptors: n(R) = sum of hours, for relays with directory request counts n(H) = sum of hours, for relays with directory write histories h(H) = sum of written bytes, for relays with directory write histories > Compute n(R\H) as the number of hours for which responses have been > reported but no written directory bytes. This fraction is determined > by summing up all interval lengths and then subtracting the written > directory bytes interval length from the directory response interval > length. Negative results are discarded. I interpret this to mean: add up all the dirrect-stats-end intervals (this is n(R)), add up all the dirreq-write-history intervals (this is n(H)), and compute n(R\H) as n(R) − n(H). This seems wrong: it would only be true when H is a subset of R. > Compute h(R∧H) as the number of written directory bytes for the > fraction of time when a server was reporting both written directory > bytes and directory responses. As above, this fraction is determined > by first summing up all interval lengths and then computing the > minimum of both sums divided by the sum of reported written directory > bytes. This seems to be saying to compute h(R∧H) (a count of bytes) as min(n(R), n(H)) / h(H). This is dimensionally wrong: the units are hours / bytes. What would be more natural to me is min(n(R), n(H)) / max(n(R), n(H)) × h(H); i.e., divide the smaller of n(R) and n(R) by the larger, then multiply this ratio by the observable byte count. But this, too, only works when H is a subset of R. Where is this computation done in the metrics code? I would like to refer to it, but I could not find it. Using the formulas and assumptions above, here's my attempt at computing recent "frac" values: date `n(N)` `n(H)` `h(H)` `n(R)` `n(R\H)` `h(R∧H)` frac 2022-04-01 166584 177638. 2.24e13 125491. 0 1.59e13 0.753 2022-04-02 166951 177466. 2.18e13 125686. 0 1.54e13 0.753 2022-04-03 167100 177718. 2.27e13 127008. 0 1.62e13 0.760 2022-04-04 166970 177559. 2.43e13 126412. 0 1.73e13 0.757 2022-04-05 166729 177585. 2.44e13 125389. 0 1.72e13 0.752 2022-04-06 166832 177470. 2.39e13 127077. 0 1.71e13 0.762 2022-04-07 166532 177210. 2.48e13 127815. 0 1.79e13 0.768 2022-04-08 167695 176879. 2.52e13 127697. 0 1.82e13 0.761 The "frac" column does not match the CSV. Also notice that n(N) < n(H), which should be impossible because H is supposed to be a subset of N (N is the set of all relays). But this is what I get when I estimate n(N) from a network-status-consensus-3 and n(H) from extra-info documents. Also notice that n(R) < n(H), which means that H cannot be a subset of R, contrary to the observations above.

2 4

tor-browser-build : any way to get it to use system packages for building?
by Jason Vas Dias 15 Jun '22

15 Jun '22

Good day - I recently attempted to check-out and build tor-browser-build - MUST it download ALL the gits, if system packages are found to satisfy version dependencies ? I just don't have enough storage / network bandwidth . Why am I downloading the llvm source when I already have llvm and clang 13 (-devel packages also) on my Fedora 36 system ? Is there any interest in producing a version of tor-browser-build to use installed system packages if they meet version requirements instead of checking out GITs & building for ALL dependencies ? It could be enabled with a USE_SYSTEM_PKGS=1 make option or something. I'm going to have to develop this if I want to work on tor-browser, which I do want to do. Best Regards, Jason

3 3

Proposal 340: Packed and fragmented relay messages
by Nick Mathewson 31 May '22

31 May '22

``` Filename: 340-packed-and-fragmented.md Title: Packed and fragmented relay messages Author: Nick Mathewson Created: 31 May 2022 Status: Open ``` # Introduction Tor sends long-distance messages on circuits via _relay cells_. The current relay cell format allows one _relay message_ (e.g., "BEGIN" or "DATA" or "END") per relay cell. We want to relax this 1:1 requirement, between messages and cells, for two reasons: * To support relay messages that are longer than the current 498-byte limit. Applications would include wider handshake messages for postquantum crypto, UDP messages, and SNIP transfer in walking onions. * To transmit small messages more efficiently. Several message types (notably `SENDME`, `XON`, `XOFF`, and several types from [proposal 329](./329-traffic-splitting.txt)) are much smaller than the relay cell size, and could be sent comparatively often. In this proposal, we describe a way to decouple relay cells from relay messages. Relay messages can now be packed into multiple cells or split across multiple cells. This proposal combines ideas from [proposal 319](./319-wide-everything.md) (fragmentation) and [proposal 325](./325-packed-relay-cells.md) (packed cells). It requires [ntor v3](./332-ntor-v3-with-extra-data.md) and prepares for [next-generation relay cryptography](./308-counter-galois-onion). ## A preliminary change: Relay encryption, version 1.5 We are fairly sure that, whatever we do for our next batch of relay cryptography, we will want to increase the size of the data used to authenticate relay cells to 128 bits. (Currently it uses a 4-byte tag plus 2 bytes of zeros.) To avoid proliferating formats, I'm going to suggest that we make the other changes in this proposal changes concurrently with a change in our relay cryptography, so that we do not have too many incompatible cell formats going on at the same time. The new format for a decrypted relay _cell_ will be: recognized [2 bytes] digest [14 bytes] body [509 - 16 = 493 bytes] "Digest" and "recognized" are computed as before; the only difference is that they occur _before_ the rest of the cell, and that "digest" is truncated to 14 bytes instead of 4. If we are lucky, we won't have to build this encryption at all, and we can just move to some version of GCM-UIV or other RPRP that reserves 16 bytes for an authentication tag or similar cryptographic object. ## New relay message packing Relay _messages_ now follow the following format: Header command u8 length u16 stream_id u16 Body data u8[length] We require that "command" is never 0. Messages can be split across relay cells; multiple messages can occur in a single relay cell. We enforce the following rules: * Headers may not be split across cells. * If a 0 byte follows any relay message, there are no more messages in that cell. * A relay cell may not be "empty": it must have at least some part of some message. Unless specified elsewhere, **all** message types may be packed, and **all** message types may be fragmented. Every command has an associated maximum length for its messages. If not specified elsewhere, the maximum length for every message is 498 bytes (for legacy reasons). Receivers MUST validate that headers are well-formed and have valid lengths while handling the cell in which the header is encoded. If the header is invalid, the receiver must destroy the circuit. ### Some examples ## Negotiation This message format requires a new `Relay` subprotocol version to indicate support. If a client wants to indicate support for this format, it sends the following extension as part of its `ntor3` handshake: RELAY_PROTOCOL version u8 The `version` field is the `Relay` subprotocol version that the client wants to use. The relay must send back the same extension in its ntor3 handshake to acknowledge support. ## Migration We add a consensus parameter, "streamed-relay-messages", with default value 0, minimum value 0, and maximum value 1. If this value is 0, then clients will not (by default) negotiate this relay protocol. If it is 1, then clients will negotiate it when relays support it. For testing, clients can override this setting. Once enough relays support this proposal, we'll change the consensus parameter to 1. Later, we'll change the default to 1 as well. ## Packing decisions We specify the following greedy algorithm for making decisions about fragmentation and packing. Other algorithms are possible, but this one is fairly simple, and using it will help avoid distinguishability issues: Whenever a client or relay is about to send a cell that would leave at least 32 bytes unused in a relay cell, it checks to see whether there is any pending data to be sent in the same circuit (in a data cell). If there is, then it adds a DATA message to the end of the current cell, with as much data as possible. Otherwise, the client sends the cell with no packed data. ## Onion services Negotiating this for onion services will happen in a separate proposal; it is not a current priority, since there is nothing sent over rendezvous circuits that we currently need to fragment or pack. ## Miscellany ### Handling `RELAY_EARLY` The `RELAY_EARLY` status for a command is determined based on the relay cell in which the command's _header_ appeared. ### Handling `SENDME`s SENDME messages may not be fragmented; the body and the command must appear in the same cell. (This is necessary so authenticated sendmes can have a reasonable implementation.) ### An exception for `DATA`. Data messages may not be fragmented. (There is never a reason to do this.) ### Extending message-length maxima For now, the maximum length for every message is 498 bytes, except as follows: - `DATAGRAM` messages (see proposal 339) have a maximum body length of 1967 bytes. (This works out to four relay cells, and accommodates most reasonable MTU choices) Any increase in maximum length for any other message type requires a new Relay subprotocol version. (For example, if we later want to allow EXTEND2 messages to be 2000 bytes long, we need to add a new proposal saying so, and reserving a new subprotocol version.) # Appendix: Example cells Here is an example of the simplest case: one message, sent in one relay cell. Here it is a BEGIN message. ``` Cell 1: Cell header circid .. [4 bytes] command RELAY [1 byte] relay cell header recognized 0 [2 bytes] digest (...) [14 bytes] message header: command BEGIN [1 byte] length 23 [2 bytes] stream_id (...) [2 bytes] message body "www.torproject.org:443\0" [23 bytes] end-of-messages marker 0 [1 byte] padding up to end of cell random [464 bytes] ``` Here's an example with fragmentation only: a large EXTEND2 message split across two relay cells. ``` Cell 1: Cell header circid .. [4 bytes] command RELAY_EARLY [1 byte] relay cell header recognized 0 [2 bytes] digest (...) [14 bytes] message header: command EXTEND [1 byte] length 800 [2 bytes] stream_id 0 [2 bytes] message body (extend body, part 1) [488 bytes] Cell 2: Cell header circid .. [4 bytes] command RELAY [1 byte] relay cell header recognized 0 [2 bytes] digest (...) [14 bytes] message body, continued (extend body, part 2) [312 bytes] end-of-messages marker 0 [1 byte] padding up to end of cell random [180 bytes] ``` Here is an example with packing only: A begin_dir message and a data message in the same cell. ``` Cell 1: Cell header circid .. [4 bytes] command RELAY [1 byte] relay cell header recognized 0 [2 bytes] digest (...) [14 bytes] message header: command BEGIN_DIR [1 byte] length 0 [2 bytes] stream_id 32 [2 bytes] message body: (empty) --- [0 bytes] message header: command DATA [1 byte] length 25 [2 bytes] stream_id 32 [2 bytes] message body: "HTTP/1.0 GET /tor/foo\r\n\r\n" [25 bytes] end-of-messages marker 0 [1 byte] padding up to end of cell random [457 bytes] ``` Here is an example with packing and fragmentation: a large DATAGRAM cell, a SENDME cell, and an XON cell. (Note that this sequence of cells would not actually be generated by the algorithm described in "Packing decisions" above; this is only an example of what parties need to accept.) ``` Cell 1: Cell header circid .. [4 bytes] command RELAY [1 byte] relay cell header recognized 0 [2 bytes] digest (...) [14 bytes] message header: command DATAGRAM [1 byte] length 1200 [2 bytes] stream_id 99 [2 bytes] message body (datagram body, part 1) [488 bytes] Cell 2: Cell header circid .. [4 bytes] command RELAY [1 byte] relay cell header recognized 0 [2 bytes] digest (...) [14 bytes] message body, continued (datagram body, part 2) [493 bytes] Cell 3: Cell header circid .. [4 bytes] command RELAY [1 byte] relay cell header recognized 0 [2 bytes] digest (...) [14 bytes] message body, continued (datagram body, part 3) [219 bytes] (488+493+219=1200) message header: command SENDME [1 byte] length 23 [2 bytes] stream_id 0 [2 bytes] message body: version 1 [1 byte] datalen 20 [2 bytes] data (digest to ack) [20 bytes] message header: command XON [1 byte] length 1 [2 bytes] stream_id 50 [2 bytes] message body: version 1 [1 byte] end-of-messages marker 0 [1 byte] padding up to end of cell random [239 bytes] ```

1 0

Firefox Add-on for torrc functions of Tor Browser
by Alessandro Greco 19 May '22

19 May '22

Premise: I had already tried to write to this mailing list, I apologize if I send another email. Hi everyone I created a Firefox extension a few week ago that allows users to use some of the Tor Browser torrc-related features through a simple and intuitive graphical interface, like Orbot App -> settings. The project is under development but I would like to share it with you proposing to include it in the tor-project project so that it can be useful and reliable for anyone who wants to use it. The extension is currently functional and allows the modification of the following features: - Changing the origin of EntryNodes (+ StrictNodes). - Changing the origin of the ExitNodes (+ StrictNodes). - Exclusion of nodes relating to a given origin on the whole circuit. - Exclusion of nodes relating to a given origin on ExitNodes. - Exclusion of unrecognized (non-geolocalizable) nodes. - Section dedicated to the torify shell command (under development). But in the last few days I have noticed that in reality the most useful and requested features by any user are only the following: - Changing the origin of the ExitNodes (+ StrictNodes). - Exclusion of nodes relating to a given origin on the whole circuit. - Exclusion of nodes relating to a given origin on ExitNodes. The extension currently requires the launch of a local script that allows communication between the extension and the torrc file. This is another reason why your control and consent is useful, in order to prove to users the script does not include malicious code. The code is obviously Open Source and I hope you can consider this project which aims to contribute to the use of Tor-Project and to the development of new features. That said, Tropea is in an experimental phase and clearly presents all the problems of an early stage of development. I want to say that if on your part there may be interest in this project then I would be happy knowing that it can be considered by your development team, otherwise it makes no sense on my part to continue to make improvements. -- Regards, Alessandro Greco. Browse my WebSite! (autistici.org/aleff) Join the Free Software Foundation! (fsf.org) Support Electronic Frontier Foundation! (eff.org) Browse Privately. Explore Freely. (torproject.org)

1 0

Network Team - New Support and Release Policy
by David Goulet 11 May '22

11 May '22

Greetings everyone! This is, for now, the last policy change from the network team after the Deprecating C Patches policy from couple days ago[0]. However, this one has a bit more impact especially on the relay operators and thus the network. We are changing the C-tor support and release policy which essentially changes "for how long" we will maintain stable releases. This will particularly affect relay operators that are using the tor stable package of their OS distribution. It is very important to use a more "current" update channel like deb.torproject.org for Debian/Ubuntu. As for BSDs, since they have a faster stable release cycle, keeping the OS updated should help getting the latest stable of tor. Here is the new policy: https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/SupportPoli… There are lots of changes but three in particular are worth highlighting and explaining: 1. No More LTS Apart from being a burden because in part due to backports complexity, they are actually a bit of a problem on the relay side with regards to the network itself. We need an healthy network and that implies, in part, to have up to date relays. Both for security reasons, but also to take advantage of the new features and defenses we roll out in the latest stable releases. We are currently suffering around 3 years upgrade path due to LTS versions that lingers in the stable OS distributions (Debian, Ubuntu, ...) for a long time. Tor is in a constant arms race against powerful adversaries, evolving technologies and resource restrictions. Fast network upgrades is instrumental to keep us in this race and provide the best security and anonymity for our users. 2. Drop the 6 months fixed stable release With 0.4.7.x series, we needed more time to roll out a version that we were satisfied with quality-wise due to not only its awesomness and complexity but because we had less people to work on the C implementation of Tor than before (some engineering power shifted to Arti development). It lead to having a much better and thoroughly tested tor without having an intermediary release with half backed features forcing us to maintain for months while being a torn in the network foot. 3. Faster End-Of-Life Path We will now only support for 3 months the previous stable once a new stable comes out. In other words, a stable version is maintained until a new stable is released plus 3 months to the date. This will also make our rejection of EOL relays from the network faster tying this to the importance of the network health with updated relays. These changes also fall into our overall efforts to shift our resources towards arti development. C-tor is not going away anytime soon, we are simply slowing down its development pace. Please, don't hesitate to ask questions and comments. We know this might not be ideal for everyone but we believe this is the best route to the sustainability of C-tor, health of the network and security for our users. Cheers! Network Team [0] https://lists.torproject.org/pipermail/tor-dev/2022-May/014731.html -- G1nLmyQttfczv2rHXvhgktvgPessxMCOKSOe/VwGY/Y=

1 0

Network Team - Deprecating C-tor Patches
by David Goulet 09 May '22

09 May '22

Greetings everyone! The network team has come up with a policy about C-tor patches in order to help and facilitate our transition to arti. The TL;DR is essentially that we will be reducing considerably the amount of patches (fixes and features) we take in for C-tor[0], most importantly on the client side, in order to alleviate the maintaining work of C-tor in favor of arti development. Please, read the following explaining why and what is changing regarding C-tor patches and development work: https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/Deprecating… Don't hesitate to ask questions! Cheers! The Network Team [0] https://gitlab.torproject.org/tpo/core/tor -- G1nLmyQttfczv2rHXvhgktvgPessxMCOKSOe/VwGY/Y=

1 0

How to get source port from conn object
by redriderbbgun11 01 May '22

01 May '22

Hey all, I want to get to know the TOR codebase so I can contribute to the project. To do this I have been doing a few projects of just doing sort of basic tasks to get an idea for how it all works together. One thing that is giving me a bit of trouble but seems like it should be simple is finding the source port for a conn object. How do I find this and moreover how do I find the actual socket behind a given connection? In connection_t I see tor_socket_t but it seems to just be an int value. Thanks

1 0

Discussion about Tor Directory Authority Consensus Code
by Zhongtang Luo 26 Apr '22

26 Apr '22

Hi all! I am a PhD student currently doing some experiments on Tor. My advisor and I was wondering if we can talk to somebody who takes care of the Tor Directory Authority code, since there is a conceptual issue we wish to communicate with them. Can somebody direct us to the appropriate person? Many thanks. Yours, Zhongtang Luo

2 1

We built a new Tor-based team chat prototype. Wanna try it?
by Holmes Wilson 15 Apr '22

15 Apr '22

Hi everyone, My collaborators and I have been working for the past couple years on building a Tor-based team chat app which we're calling Quiet*, and I'm curious if anyone here would like to try it out! If you would, please reply! :) I am especially interested in feedback from Tor project participants and people who are sometimes in the position of advising organizations on their security needs, but everyone on this list is welcome! What I'll try to do is find a time that would work for all of us so we can try it together in a true test of its team chat possibilities, though if that doesn't work I'm happy to do one on one meetings too. Quiet is still lacking pretty much every feature imaginable except adding team members and sending and receiving messages. And mobile apps aren't ready yet. And it hasn't been audited so it shouldn't be used for anything important at all. And so on. But if you've tried any attempts at p2p group chat before, this one will strike you as surprisingly reliable thanks in no small part to the reliability of Tor. So it's pretty cool to see it in action and it's a fun new way to use Tor. Again, I'm not looking for any real end users at this stage—we're just not ready for that yet. But we've invested a lot in usability and reliability and we're making a really serious go of it. This isn't vaporware and I think it'll be worth your time to check it out! :) Perhaps the coolest part about our approach is that its usefulness goes way beyond chat apps. The approach we've taken is adequate for building private, F/OSS alternatives to a large class of crucial applications that currently lack strong privacy and security properties, such as Trello, Asana, Basecamp, Google Docs and Sheets, Figma, Discourse, Airtable, team password managers, and more. Specifically, you can use it to build any application where a bounded group of people share some common workspace, as long as the data would fit on a typical consumer device. And perhaps from that foothold we can figure out ways to extend the model to be adequate for building large unbounded networks like Signal, Twitter, and Facebook in a decentralized way, though that's a much harder class of problem. (I gave this talk <https://archive.org/details/hopeconf2020/20200802_1600_Zbay%2C_Fighting_FAA…> a couple years back at HOPE 2020 about these ideas which is a pretty good overview of the motivations behind the project, and and I'll be speaking again at HOPE 2022 this summer about where we're at now, so it would be great to meet up there if anyone else will be there!) I've included some more notes below on how it works for those who are curious. But if you're curious please write me back so I can give you a demo :) Holmes # How it works Quiet is like a combination of Slack and Ricochet. Ricochet did not depend on any servers except for the Tor network itself, and sent messages directly over onion services, but it was only for 1:1 messaging. Like Ricochet, Quiet doesn't require any servers except for the Tor network itself, but it uses some p2p libraries that have emerged over the past few years to enable group chat where—like Slack and Discord—all clients tend to display the same message history, even clients that were offline when messages were sent. Specifically, Quiet uses OrbitDB, a CRDT. CRDTs are sort of like Git, where they enable syncing between decentralized peers such that all peers eventually converge on the same state. OrbitDB is built on IPFS, so unlike a lot of CRDTs (like Automerge) it comes with some built-in ability to move data around between peers. IPFS is pretty flexible and we set it up so that each team has its own totally isolated IPFS network, and all the IPFS clients connect to each other over Tor. There's no big, global, leaky p2p network, and no blockchain or anything like that. You have a group of friends, and you just talk to each others onions. That's it. To invite a new user, an authorized user shares an onion service link to a "registrar" onion service running on their machine, and they add that new user's key information to a user table, and give the user a certificate they can use to connect to other peers. A single community owner uses certificates to grant unique usernames. Mobile apps use the same approach, though we'll need a centralized service for notifications on iOS until someone changes the way Apple Apples, and we haven't built that yet. There are a lot of other important pieces of the design we haven't tackled yet too, such as timed message deletion, removing users, use of onion auth for incoming connections, optimizations for very large communities, and so on. But it's all fairly tractable, if a bit slow going. (I'm also really interested if this description is clear and would love your feedback and questions!)

1 0