- tor-dev - lists.torproject.org

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

A proposal to phase out CAPTCHAs for BridgeDB
by Cecylia Bocovich 02 Aug '21

02 Aug '21

Hi everyone, We've been working on improving the usability of BridgeDB lately, and our CAPTCHAs have been a constant thorny problem. They are not accessible for blind users [0]. We've gotten many complaints over the years that they are hard to use [1], I'm sure Gus and the community team members can vent about the impact they've had on users. We even have some evidence that bots have been able to enumerate our CAPTCHAs just fine [2]. There are other anti-enumeration defences on BridgeDB that are perhaps more useful including: - partitioning bridges into buckets based on IP subnet: A user who requests bridges from a single IP address or multiple IP addresses from the same subnet won't be able to see every bridge. - time-locking access to bridges: The set of bridges that BridgeDB distributes to users during a single time period is locked to a small number. Repeated requests for bridges during that time period will return the same 3 bridges to the user. We haven't done a lot of experimenting with tuning these parameters to slow bridge enumeration attempts. For the most part, on the country level, censors that are willing to put the effort into blocking BridgeDB bridges seem to be pretty effective at it regardless of CAPTCHAs. The GFW blocked all of the new bridges from our 2019 bridge campaign in less than a month [3]. There was a recent case of censorship in Belarus where state censors blocked all of BridgeDB's email distributed bridges, but weren't able to enumerate bridges distributed over Moat or HTTPS [4]. It's possible that that CAPTCHAs were the reason behind this, but it's hard to know for sure. I would like to propose that we remove the CAPTCHAs from BridgeDB entirely, but I'd like to know whether there is research out there *specifically that fits with the anti-censorship context* showing that these CAPTCHAs are actually doing useful work to prevent Bridge enumeration. But, even if the CAPTCHAs are preventing a small number of censors from enumerating more bridges, is the usability impact worth what marginal benefit we get from it? Options for how to move forward: Option 1: Just remove the CAPTCHAs already! We're tired of waiting and just want our bridges. Option 2: Do some science? We could make a new distribution bucket in BridgeDB that distributes bridges through Moat without a CAPTCHA and have new versions of Tor Browser pull from this bucket. We can watch and perform measurements in places we know enumeration attempts have occurred in the past and see whether these bridges are enumerated more quickly and more completely than the old-school Moat bucket. Option 3: Keep doing what we're doing but try to make the CAPTCHAs more usable. This is the work we've had planned, but will only get us so far. Endpoint enumeration is a tricky topic and we do have some other alternatives in the pipeline. Conjure is more of a "blocking resistance through collateral damage" approach that's somewhat similar to domain fronting [5]. We've been looking at and hope to do more work in the future on reputation-based bridge distribution [6]. I see these as more promising than CAPTCHAs in the long run, and CAPTCHA-less BridgeDB bridges seem to still fill a need that built-in bridges and private bridges don't fill. I'd appreciate any thoughts, comments, or experiences others have! Cecylia [0] https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/10831 [1] https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/24607 [2] https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/32117 [3] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfs… [4] https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/blo… [5] https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/9 [6] https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31873

4 3

Scalability or Onionbalance for v3 ephemeral/ADD_ONION services
by Chad Retz 26 Jul '21

26 Jul '21

A quick glance at the code shows that ADD_ONION (i.e. "ephemeral" onion services) doesn't support setting an Onionbalance frontend/master onion address (specifically https://gitlab.torproject.org/tpo/core/tor/-/issues/32709 doesn't seem to have a control-side analogue). Would a feature request for adding a `*(SP "OnionbalanceMasterKey=" OBKey)` (or "OBMasterKey" or whatever) to ADD_ONION be reasonable? If so, just add in Gitlab? Also curious alternative scalability and load balancing options for ephemeral v3 onion services. I have read https://www.benthamsgaze.org/wp-content/uploads/2015/11/sucu-torscaling.pdf but unsure if anything more recent has been written. Beyond that and Onionbalance, any other interesting approaches I could employ (assuming I can dev anything from a control port pov, but am wanting to work w/ an unmodified Tor binary)? Thanks, Chad

3 5

A series of questions about Tor (m1 support, forward secrecy, v3 auth)
by Holmes Wilson 26 Jul '21

26 Jul '21

Hi everyone, A few disjointed questions that have come up recently in our work with Tor: 1. PERFORMANCE ON M1 / ARM64 We just got a report from a user that the tor binary for Mac was using much more CPU on Apple Silicon / M1 than it used on Intel. Has anyone scene anything like this? Is there an arm64 build of tor binary for Mac, existing or in the works? (Related: do Tor developers have a few M1 Macs to test on? We could probably donate one if not!) 2. FORWARD SECRECY Is there a good source for documentation on how forward secrecy works in Tor, and on what security guarantees it provides? Googling finds things like this reddit post (https://www.reddit.com/r/TOR/comments/cryrjx/does_tor_use_pfs/) but I can’t find any detailed information about it, what threat models it fits, etc. One specific question is, if two users are communicating by sending messages over a connection to an onion service (like ricochet) and an attacker surveils their internet traffic and compromises their devices at a later date, will the attacker be able to recover the clear text of their conversation? When are keys for a given connection destroyed? Does it happen continuously throughout the course of a Tor connection? Or on the creation of a new circuit? Or what? 3. V3 AUTH AND DOS ATTACKS Does v3 onion authentication protect against DOS attacks? That is, can someone who is not authorized to connect to an onion address with authentication enabled still cause problems for that onion address? Can they connect to it at all, in the sense of being able to send data to the tor client at that onion address? Or does the Tor network itself prevent this connection from even happening? A related question is, if we’re looking to deny connections to an onion address to any unauthorized users, and we’re considering turning off onion authentication and implementing some standard authentication scheme that seems fairly well-supported at the web server layer, is there any security-related reason why we would be better off using Tor’s own authentication instead? Using our own authentication scheme will be a bit easier to control, rather than having to send commands to Tor (and possibly restart it for removing users?) but I’m wondering if there are security properties we lose by doing that. Thanks! Also, apologies if any of these questions aren’t clear or well-formed! Holmes

4 4

The Tor Project hiring software engineers
by Gaba 22 Jul '21

22 Jul '21

Hi! We have a few positions open right now. Please apply or share it in your networks! Rust developers for the network team (to work on Arti): http://torproject.org/about/jobs/rust-dev/index.html Anti-censorship engineer to work mostly in Go and with focus on China: http://torproject.org/about/jobs/software-developer-anticensorship-2/index.… C++ and Javascript developer to work with our applications team (the one maintaining Tor Browser): http://torproject.org/about/jobs/software-engineer-applications-team/ Thanks! -- pronouns she/her/they GPG Fingerprint EE3F DF5C AD91 643C 21BE 8370 180D B06C 59CA BD19

1 0

Arti development report: July 7 through July 21
by Nick Mathewson 21 Jul '21

21 Jul '21

# Arti Report 2: July 7 through July 21 It's been a quiet couple of weeks. Most of the team has been on vacation or leave for the last two weeks, so the Arti hacking has been down to me (nick) for this period. Our last report went out on the same day that our [announcement] went public, and since then we've had an influx of attention and volunteers interest. Thanks to everybody who's been trying out the code! Special thanks to `trinity-1686a` for a [stream-isolation] implementation, `lyuyuan` for work on [RESOLVE and RESOLVE_PTR][resolve], and everybody else who's been submitting patches! ## Circuit timeout inference My own work for this period has focused on [circuit timeout inference][cti]. (I decided to start with this because it's part of the Tor protocol that I've worked with the least in the past.) The approach is kind of complicated: in order to adjust our timeout, we need to observe how long circuits actually take to complete... including the circuits that we don't use because they take longer than our current timeout timeout. So we have to keep building circuits for a while even after they time out, so that we can observe how long it takes them to finish. Then we use an estimator based on a Pareto distribution, and use that to determine our actual cutoffs. The core logic is now [implemented in Arti][pareto-code], and we just have a few more pieces ([persistence][ticket-143], [directory notification][ticket-144], and [testing circuits][ticket-145]) to cover before we can call it done. ## Open problems Our timeout tests rely on using a simulated view of time. (Nobody wants to wait 10 seconds for a simulated 10-second timeout!) For that, we have [testing code][rt-mock-time] to override the asynchronous runtime's view of the passage of time. But we have a bug somewhere that makes these tests unreliable. The [WaitFor] future, which is supposed to run a another future to completion while advancing the current (simulated) time, doesn't seem to be reliable. As implemented, it advances the current time even when the future it's testing _isn't_ blocked on time, and sometimes advances time much too far while the tested future makes no progress. I've kludged it up by making it yield a lot and advance time in tiny increments, but that's just a workaround. Does anybody like [debugging Futures code][ticket-149]? ## Next steps In the next two weeks I hope we can wrap up the outstanding issues above in circuit timeouts, including the ones that require some architectural decisions. I'm also hoping that we can make progress on [guards]: that's the last remaining really big security feature we have to do for our 0.0.1 milestone. Once that's done, we can move on to polishing and infrastructure issues for the rest of the time we have for this milestone. Finally, we're going to be expanding our team! Please have a look at our [job-opening], and share it with anybody you know who is interested in Rust and Tor, and who might be interested in a job. Next update in two weeks! [announcement]: https://blog.torproject.org/announcing-arti [cti]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/path-spec.txt#… [cti]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/guard-spec.txt [job-opening]: https://www.torproject.org/about/jobs/rust-dev/ [pareto-code]: https://gitlab.torproject.org/tpo/core/arti/-/blob/main/tor-circmgr/src/tim… [resolve]: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/39 [rt-mock-time]: https://gitlab.torproject.org/tpo/core/arti/-/blob/main/tor-rtmock/src/time… [stream-isolation]: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/38 [ticket-143]: https://gitlab.torproject.org/tpo/core/arti/-/issues/143 [ticket-144]: https://gitlab.torproject.org/tpo/core/arti/-/issues/144 [ticket-145]: https://gitlab.torproject.org/tpo/core/arti/-/issues/145 [ticket-149]: https://gitlab.torproject.org/tpo/core/arti/-/issues/149 [WaitFor]: https://gitlab.torproject.org/tpo/core/arti/-/blob/main/tor-rtmock/src/slee…

1 0

Weaving a Faster Tor: paper/video of possible interest
by Ian Goldberg 20 Jul '21

20 Jul '21

Hello tor-dev, Steve Engler (currently part of the Shadow team) and I have a paper of possible interest to appear at ARES 2021 next month. It's a design of a multi-threaded relay architecture, of possible particular interest when considering relay support in arti, for example (though the proof-of-concept implementation is based on the usual C codebase). If you're interested, here are previews of: Paper: https://cs.uwaterloo.ca/~iang/pubs/mttor-ares21.pdf Video: https://www.youtube.com/watch?v=41a6nLUJye8 Code: https://git-crysp.uwaterloo.ca/sengler/tor-parallel-relay-conn https://git-crysp.uwaterloo.ca/sengler/relay-throughput-testing -- Ian Goldberg Canada Research Chair in Privacy Enhancing Technologies Professor, Cheriton School of Computer Science University of Waterloo

4 4