- tor-dev - lists.torproject.org

Proposal 334: A flag to mark Relays as middle-only
by Tor Relays 16 Sep '21

16 Sep '21

David Goulet: > However, I'm not sure we should always let 1 authority dictate that flag > regardless of what the others think. > > I think we need to enforce majority here and not have one > single authority dictate it. > > Thoughts? > +1 I can compromise one authority and can MiddleOnly the whole Tor network.

2 1

Arti report 5: August 18 through September 15
by Nick Mathewson 15 Sep '21

15 Sep '21

# Arti Report 5: August 4 through September 15 ## Activities since our last report I'm back, with updates from the last month! We've spent a lot of time over the last on cleaning up technical debt issues in our code that had accumulated as I wrote it. There are more tests and warnings enabled than before, and we've changed some new internal APIs to make them unable to panic. We're also using the [`derive_builder`][derive_builder] tool to throw out a bunch of boilerplate code. When I wrote last month, I'd just finished up the implementation for circuit build timeout inference. As followup work to that, I worked with Mike Perry to collect all of the missing specification issues that I'd found while cloning that feature, and [roll them back][torspec-mr-40] into our `path-spec.txt` document. Mike'sw found a couple of mistakes in my implementation that I was able to resolve—fortunately, by removing code from the Arti timeout inference code. ## Getting a head start on API design API design will be the focus of our 0.1.0 release, but we still want to get it "as right as we can" in the upcoming 0.0.1 version. With that in mind, we've started enumerating the various kinds of programs and environments that we need to support down the road, and [working on a list of example programs][ticket-164] that we might be able to ship with Arti. (My own experience so far is that writing example code is just about the best way to find API deficiencies.) ## Uplifting new features from C Tor For our work on congestion control, we're getting a new [circuit extension handshake][prop332]. Going forward, as we add features to C Tor, we're going to try to add them to Arti at around the same time. With that in mind, we have the new handshake implemented (but not enabled): we used its implementation to validate our specifications double-check our test vectors. ## Towards guard support Our largest remaining priority for Arti 0.0.1 is full support for [guard nodes][guard-spec]. (In Tor, a "guard node" is a relay that a client decides to use as the first hop for all of its circuits for a long time. Using guard nodes improves resistance against many kinds of attacks based on hostile relays.) We've started laying the groundwork here: we now have support for all of the guard-related consensus parameters, and we've reworked our relay selection code to allow picking multiple weighted random items without replacement. We've also added some previously unneeded lookup-by-ID features to network directory code. (Fun fact: the Tor implementation of mapping IDs to relays has been historically ugly, since we don't really know a relay's ed25519 identity until we have a microdescriptor for it. In C, this has led to a reasonably messy pile of dangling pointer bugs…which Rust won't even let us write! Also, we've made better design choices in Arti about our directory objects, so we don't have do support all of the strange mutability that our C code had to try to handle.) We're now in the midst of coding up a guard implementation. The tricky part here is that our guard logic affects circuit building selection (since circuit paths must begin with a guard), but circuit construction affects guard selection. We're experimenting with different designs to try to keep the complexity here under control. # Thanks to awesome volunteers! Thanks to Jani Monoses for migrating Arti to the tracing crate and adding journald support; to Robin Leander Schröder for cleaning up some of our `unwrap_or()` code; to S0AndS0 for work enabling the `unwrap_used` Clippy lint; to Daniel Eades for work cleaning up Clippy lints in our test modules, and to Trinity Pointard for work on stream isolation and reproducible builds! [ticket-164]: https://gitlab.torproject.org/tpo/core/arti/-/issues/164 [prop-332]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/332-nt… [derive_builder]: https://crates.io/crates/derive_builder [torspec-mr-40]: https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/40 [guard-spec]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/guard-spec.txt

1 0

Proposal 334: A flag to mark Relays as middle-only
by ezhigp＠Safe-mail.net 14 Sep '21

14 Sep '21

Neel Chauman wrote at Sun Sep 12 19:17:37 UTC 2021: >my updated proposal >says that if one dirauth gives a relay the MiddleOnly flag, then it's >set for that relay. This is to prevent harm while all (or the majority >of) dirauths give the relay that flag. Imagine one hostile dirauth that votes for this flag on every relay it cannot control. Guessing the result is left as an exercise to the reader :). (Spoiler: IIUC, this will result in using only attacker-controlled relays as entries and exits, resulting in both-ends control of all external and hidserv circuits).

1 0

No arti report this week.
by Nick Mathewson 01 Sep '21

01 Sep '21

Hi! Usually I do Arti reports every other Wednesday, but this week I'm on vacation. I'll send the next report on September 15, so that the reports can be offset from the Arti meetings. cheers, -- Nick

1 0

Next public Arti meeting happening on September 8th at 1500 UTC
by Gaba 26 Aug '21

26 Aug '21

Hi! We are canceling the meeting on September 1st. Our next meeting will be on September 8th (and then every 2 weeks). Meeting's room: https://tor.meet.coop/gab-sis-ldw-xad Meeting notes in: http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/art… Recording of previous meetings: https://www.youtube.com/playlist?list=PLwyU2dZ3LJErozq7cTtImuWkSn_34pEpq Agenda - status of Arti development and planning - user stories for Arti API https://pad.riseup.net/p/MUjnic0eRT0WrDW7M-us cheers gaba -- pronouns she/her/they GPG Fingerprint EE3F DF5C AD91 643C 21BE 8370 180D B06C 59CA BD19

1 0

Arti report 4: August 4 through August 18
by Nick Mathewson 18 Aug '21

18 Aug '21

# Arti Report 3: August 4 through August 18 At last we're done with circuit timeout inference! See the last weeks update for an overview of what this was, and why it was hard. As of last Friday, we've finally got an Arti implementation that builds testing circuits as appropriate, infers reasonable timeouts, and remembers those timeouts across runs. As a side-benefit to this work, we've found a number of points where we need to clarify the Tor specification to be more precise about correct behavior for a Tor client. (For example, how to break ties when deciding on the most populous histogram bins.) I'm taking some time to circle back and fix those in the Tor specs. Here is the first recorded persistent state from an Arti implementation, lightly reformatted: version = 1 histogram = [[415, 1], [495, 2], [515, 1], [535, 1], [545, 1], [555, 1], [625, 1], [655, 1], [665, 1], [785, 1], [835, 1], [865, 2], [885, 3], [955, 1], [965, 1], [975, 2], [985, 1], [1005, 2], [1025, 1], [1035, 2], [1055, 3], [1065, 1], [1075, 1], [1085, 2], [1095, 1], [1115, 2], [1135, 2], [1145, 2], [1175, 1], [1185, 1], [1195, 2], [1205, 3], [1215, 1], [1235, 2], [1245, 6], [1255, 1], [1265, 2], [1285, 2], [1295, 3], [1305, 1], [1315, 1], [1355, 2], [1375, 2], [1385, 2], [1405, 2], [1435, 1], [1455, 1], [1465, 1], [1495, 1], [1505, 1], [1525, 1], [1535, 1], [1555, 1], [1565, 1], [1605, 1], [1625, 1], [1665, 1], [1765, 1], [1785, 1], [1825, 1], [1965, 1], [2165, 1], [2495, 1], [3025, 1], [3855, 1], [4265, 1], [4795, 1], [4935, 1], [5435, 1], [6825, 1]] current_timeout = 1592 abandoned_circs = 0 successful_circs = 20 ## Other work We've continued to review and merge volunteer patches. Thanks, everybody! In response to a patch documenting a number of possible panics, I've taken a pass through the code to reduce the number of functions that could panic. I've also been spending some time improving test coverage: while doing so, I found an incorrect behavior when checking whether two IPv6 addresses were on the same network. (Tests are great and need to be everywhere, apparently.) ## Coming up Our current priorities are: * Starting API design work. So far we've been feeling our way forward, and it's time to get more systematic. * Improving our APIs and internal functionality for stream isolation, to support a variety of usecases more like what can be done with current Tor. * Kicking off the work on a Guard implementation. This is the last key feature we need for a basic level of privacy. * Lots more interviewing job candidates. Let's see how far we get in the next two weeks!

1 0

txtorcon 21.1.0
by meejah 16 Aug '21

16 Aug '21

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I'm pleased to announce txtorcon 21.1.0. This fixes some incorrectly-skipped tests in 21.0.0 * Fix some incorrect unit-test skipping logic (thanks Jean-Paul Calderone) https://github.com/meejah/txtorcon/issues/354 and https://github.com/meejah/txtorcon/issues/352 * Fix broken tests revealed by previous fixes (thanks Jean-Paul Calderone) https://github.com/meejah/txtorcon/issues/356 You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/21.1.0 https://github.com/meejah/txtorcon/releases/tag/v21.1.0 Releases are also available from the hidden service: http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check aebf0b9ec6c69a029f6b61fd534e785692e28fdcd2fd003ce3cc132b9393b7d6 dist/txtorcon-21.1.0.tar.gz bcc54299e5119d6a9ace889bbefc1ff93108a204824b738e9c77bdb71f61661f dist/txtorcon-21.1.0-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCgAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAmEa1UoRHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaad3/gf/S0mneFfvY0CdqR3DyIOgjX29lIotkDzf 1SeTnLdSU2SYXj89d8TnCUONkQiFZvruGcQufASA+mbIFKC+2KwZ7BVJLlYJ9MGu Cyjt+1jr2xXGmAEVqLcDwCZM7v4BknD/W2jxZqLx3CjDuU3U1abjcJUBlt2Pq/uA B5wWK6PAxIE1rksGtk+ftMf+jMIRwTb5hNj9HynDuGzW3MFbmanyQh2eBfQPlrve 1FqmQUEaOKMM6S34mvExRIjB5/q1SNs8+zX9oAR5wrLh3NVCsiVyXtVOvU949sLy HKVm9nHzgemRrj/nsKetLahM5MYpRYFMhZVYTK+nyotK+I5tRfrXGQ== =e+mc -----END PGP SIGNATURE-----

1 0

This week's arti meeting rescheduled: 18 August, 1600 UTC
by Nick Mathewson 16 Aug '21

16 Aug '21

Hi! Because of a scheduling conflict, our biweekly Arti meeting is rescheduled (for this Wednesday only). The time this week will be at 18 August, 1600 UTC, at https://tor.meet.coop/gab-sis-ldw-xad . This week we'll be brainstorming API ideas, use cases, and user stories. Don't worry if you can't make it: we record our meetings and put them online on Tor's youtube channel. (And this won't be your last chance to influence the API; it's just an initial brainstorming session.) cheers, -- Nick

1 0

GSoC 2021 - Alexa Top Sites Captcha and Tor Block Monitoring #Update
by Apratim Ranjan Chakrabarty 09 Aug '21

09 Aug '21

Hi, Since my previous updates I've come up with a near working system that fetches data from different browsers via a control node and exit relays, and analyzes the different results, and further renders and plots the data into the localhost of the system. Areas where work is pending: + The Captcha Monitor is working and producing data-points, provided "captchamonitor-tor-container" works correctly. As of now I do have data but not much. Can check here:[0].The fault in container is that it turns unhealthy and therby the application doesn't work, as it depends upon the "captchamonitor-tor-container". Tickets regarding this are: [1],[2]. So this will be one of my tasks to complete as more the data, more will the cases to look for and access the working. + Create more graphs which would provide more insights and data to the users[3]. + Reviews from the Community: For the dashboard [0], I'll add the search bar which as of now is disabled. Further on clicking the individual Relay it redirects to the detailed page based on relay. As of now there are a lot of directions where it could be improved, one possible example could be the UI of the website. This is a field I would require some help from the community for ideas on improving it. That being said, I'm maintaining more on to-dos and resources here: [4]. Again,feel free to add more resources and discussions here as to what you feel could be added or removed and help a better working for the system. Thanks, Apratim References: [0]: http://20.85.221.64:5000/dashboard.html [1]: https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/issues/95 [2]: https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/issues/99 [3]: https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/issues/88 [4]: https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/issues/96

1 0

Arti Report 3: July 21 through August 4
by Nick Mathewson 05 Aug '21

05 Aug '21

Still quiet here for the last couple of weeks. I've been moving ahead on circuit timeout inference, and reviewing _lots_ of volunteer-submitted code (and job applications). The quiet part is coming to an end: Two of the engineers who have been on vacation or leave are back, and we're all trying to ramp up. We're also hoping to be scheduling interviews with prospective co-workers soon, so that's taking up some of our time.. but once it's done, it should accelerate our pace a bit. ## Circuit timeout inference logic I had hoped to be done with this by now, but it turns out that this code touches on several key architectural issues that we'll want to make sure we get right in the future. I'll touch on them a bit here. ### Persistent state The Tor protocol requires clients to keep persistent state across invocations in order to achieve good performance and privacy. Two notable cases of this are in the circuit management code: client need to remember circuit timeout data, and need to remember guard selection data. The C Tor client records these items in the same ad-hoc format used by Tor's configuration code. But for Rust, using serde seems like a better fit. I want to maintain the feature that Arti has now where you can run multiple processes with the same state directory. That could get tricky in the long run, but I think it's a design feature we need if we're going to keep Arti flexible enough for general use. My first implementation here is going to be bare-bones, but I'm trying to design it to grow and get replaced down the line. ### Inter-module event notification Frequently one module needs to notify another when some event occurs. In the circuit-timeout case, we need to notify the circuit manager whenever the network parameters have changed. We don't want to have the circuit manager probing the directory manager, since that's a higher-level module. And we don't want it probing the `NetDir` object it gets whenever it's time to build a circuit, since that would be a weird side-effect. The best I've been able to come up with for now is to allow the directory manager to expose a `Stream` of events for directory changes, and to have the `TorClient` object use events from that stream to alert the circuit manager to possibly changed network parameters. I think this should scale to other kinds of inter-module events in the future, though I do have a slight concern that it makes `TorClient` harder to reproduce with lower-level crates than it would be otherwise. (There's probably no avoiding that at this stage, though.) ### Non-user-initiated background tasks The circuit timeout code sometimes needs to build testing circuits in order to gather data, and the guard code does too. If we code this in a sloppy way, we'll wind up with three separate systems that all build circuits for different reasons at different times. With any luck, we can summarize the triggers from all of these circuit types into a single system. ## Coming up We've been working on refinements to the API in `arti-tor-client` to try to simplify the API as much as possible while still exposing the full back-end functionality. Everybody should expect a lot of unstability here. I am still hoping very much that the next time I write one of these reports, we'll be done with circuit timeout inference, and I can talk about API work and early progress on guards! :)

1 0