- tor-dev - lists.torproject.org

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 26 Jun '22

26 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 14 Jun '22

14 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