tor-dev May 2022

tor-dev@lists.torproject.org

5 participants
8 discussions

Two features that would help load-balanced bridges
by David Fifield 01 Jun '23

01 Jun '23

After the blocking of Tor in Russia in December 2022, the number of Snowflake users rapidly increased. Eventually the tor process became the limiting factor for performance, using all of one CPU core. In a thread on tor-relays, we worked out a design where we run multiple instances of tor on the same host, all with the same identity keys, in order to effectively use all the server's CPU resources. It's running on the live bridge now, and as a result the bridge's bandwidth use has roughly doubled. Design thread https://forum.torproject.net/t/tor-relays-how-to-reduce-tor-cpu-load-on-a-s… Installation instructions https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Gui… Two details came up that are awkward to deal with. We have workaround for them, but they could benefit from support from core tor. They are: 1. Provide a way to disable onion key rotation, or configure a custom onion key. 2. Provide a way to set a specific authentication cookie for ExtORPort SAFE_COOKIE authentication, or a new authentication type that doesn't require credentials that change whenever tor is restarted. I should mention that, apart from the load-balancing design we settled on, we have brainstormed some other options for scaling the Snowflake bridge or bridges. At this point, none of these ideas can immediately be put into practice, because there's no way to tell tor "connect to one of these bridges at random, but only one," or "connect to this bridge, but accept any of these fingerprints." https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… # Disable onion key rotation Multiple tor instances with the same identity keys will work fine for the first 5 weeks (onion-key-rotation-days + onion-key-grace-period-days), but after that time the instances will have independently rotated their onion keys, and clients will have connection failures unless the load balancer happens to connect them to the instance whose descriptor they have cached. This post investigates what the failure looks like: https://lists.torproject.org/pipermail/tor-relays/2022-January/020238.html Examples of what could work here are a torrc option to set onion-key-rotation-days to a large value, an option to disable onion key rotation, an option to set a certain named file as the onion key. What we are doing now is a bit of a nasty hack: we create a directory named secret_onion_key.old, so that a failed replace_file causes an early exit from rotate_onion_key. https://gitweb.torproject.org/tor.git/tree/src/feature/relay/router.c?h=tor… There are a few apparently benign side effects, like tor trying to rebuild its descriptor every hour, but it's effective at stopping onion key rotation. https://lists.torproject.org/pipermail/tor-relays/2022-January/020277.html # Stable ExtORPort authentication ExtORPort (extended ORPort) is a protocol that lets a pluggable transport attach transport and client IP metadata to a connection, for metrics purposes. In order to connect to the ExtORPort, the pluggable transport needs to authenticate using a scheme like ControlPort authentication. https://gitweb.torproject.org/torspec.git/tree/proposals/217-ext-orport-aut… tor generates a secret auth cookie and stores it in a file. When the pluggable transport process is managed by tor, tor tells the pluggable transport where to find the file by setting the TOR_PT_AUTH_COOKIE_FILE environment variable. In the load-balanced configuration, the pluggable transport server (snowflake-server) is not run and managed by tor. It is an independent daemon, so it doesn't have access to TOR_PT_AUTH_COOKIE_FILE (which anyway would be a different path for every tor instance). The bigger problem is that tor regenerates the auth cookie and rewrites the file on every restart. All the tor instances have different cookies, and snowflake-server does not know which it will get through the load balancer, so it doesn't know what cookie to use. Examples of what would work here are an option to use a certain file as the auth cookie, an option to leave the auth cookie file alone if it already exists, or a new ExtORPort authentication type that can use the same credentials across multiple instances. What we're doing now is using a shim program, extor-static-cookie, which presents an ExtORPort interface with a static auth cookie for snowflake-server to authenticate with, then re-authenticates to the ExtORPort of its respective instance of tor, using that instance's auth cookie. https://lists.torproject.org/pipermail/tor-relays/2022-January/020183.html

2 2

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

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

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev May 2022