- tor-dev - lists.torproject.org

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

Interoperation with libp2p
by Mike Mestnik 07 Apr '22

07 Apr '22

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

5 5

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

27 Mar '22

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

2 2