- tor-dev - lists.torproject.org

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

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

20 Jul '21

Hi everyone! Been quite sometime since the last update but if one wants to see the details in between one could go to the DIAL blogs for the project[1]. As of now, we do have a working project with the following details implemented [2] and further the dotted[consensus module], idea taken from Senser paper[3] haven't been implemented yet, but hopefully I'll implement it within a week or two at most. I personally was tilted towards the similarity of the structure but after some discussions with woswos and Micah Sherr[4], I've thought of implementing the content based approach too. I'll briefly describe both the methods below: + Structure of the website: This was thought of because we don't really know what various changes would be there for a website. More specifically would be useful for dynamic websites, websites with language based on geolocation (Geotargeting). But I have to use a filter list and statistical method to approach the problem. + Content based Approach: Compares the content of the HTML data using tree like structure and hashes to know how the structure is different or similar. Usage of proxies of the same locations as vantage points to get better results. That said, the above mentioned methods are used for the case where websites partially block tor. One good example for this case would be https://dan.me.uk/ which doesn't block tor exit relay nodes completely, but gives an error page (partial block) and no error HTTP response code. The checking of the HTTP response codes being a low-hanging-fruitish algorithm is our first step which is seen performing good and might sometimes result in false positives (Says a website like https://cloudflare.com to be blocked completely, when it returns captcha or is partially blocked). Further for the demo purpose, one can refer to the Experimental code[5] and it's log[6] (Isn't much of a good code and is a bit old but wrote to serve the purpose of backing up the first method (Structure of the website)). Also one could look into the `Analyzer.py`[7,8] which would contain the most recent and improved logic to the analysis. Hope to improve it with every passing day. I also plan to create a FAQ[9] page which would have excerpts of discussions or answers to as why a following approach was taken. Thanks, Apratim (irc: _ranchak_) ** Looking forward for suggestions and comments as to how to improve on it. Also materials like research paper in this domain would be helpful ** References: [1] https://hub.osc.dial.community/t/tor-project-alexa-top-sites-captcha-and-bl… [2] https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/wikis/GSoC-2021#upda… [3] http://people.cs.georgetown.edu/~wzhou/publication/senser-acsac13.pdf [4] https://seclab.cs.georgetown.edu/msherr/ [5] https://github.com/Hackhard/Fetcher/blob/b9f2fa8d09061862cf954537cbaad7921d… [6] https://raw.githubusercontent.com/Hackhard/Fetcher/main/status%20code/test_… [7] Consensus_lite branch: https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/blob/consensus_lite/… [8] Master branch: https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/blob/master/src/capt… [9] https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/wikis/GSoC-2021/Faqs

2 1

Mostly Automatic Censorship Circumvention in Tor Browser
by Richard Pospesel 08 Jul '21

08 Jul '21

Hi Everyone, As part of our Sponsor 30 work, we are looking to improve the new about:torconnect experience by adding automatic tor settings configuration for censorship circumvention. This document outlines and discusses the *technical* challenges associated with this work, and does not go into any great detail on the right UX would be (in terms of easy of use, user trust, etc). Anyway, if you see any pitfalls or problems with anything here, do let us know. ------------------------------8<-------------------------------------- # Mostly Automatic Bridge Configuration to Bypass Internet Censorship Our goal for this work is to enable Tor Browser users to access tor without having to navigate to about:preferences#tor to configure bridges. Technically speaking, this is a trivial problem assuming you know: - which bridge settings work at the user's location - the location of the user ## Circumvention Settings Map For now, it seems sufficient to maintain a map of countries to some data-structure containing information about which censorship circumvention techniques work and which ones do not. A proposed example format can be found here: - https://gitlab.torproject.org/tpo/anti-censorship/state-of-censorship/-/blo… This map would at be distributed and updated through tor-browser releases. ### Problems #### Censorship Changes Invalidate the Map The obvious problem with distributing the censorship-circumvention settings map with Tor Browser is that if the techniques used in a location change such that old settings no longer work, you will be left with a non-functional Tor Browser with no way to update it apart from acquiring a fresh install with the updated settings or by manually configuring Tor Browser's bridge settings (so what users have to do now) A fix for this would be to provide a rules update mechanism whereby updated rules could be fetched outside of tor (via the clearnet, or over moat). Special care would need to be taken to ensure the rule updates from this automatic mechanism actually came from the Tor Project (via some sort of signature verification scheme, for example). Another wrinkle here is that rules would also need to be distributed somewhere that is difficult to censor. It seems likely that we may need different locations and mechanisms for acquiring the rule-set based on the user's location. Whatever the mechanism, updates should happen at least before the user attempts to auto-configure. Otherwise, perhaps we should periodically auto-update the the settings at a reasonable cadence. #### Time Investment to Update Map Another problem with solely distributing the rules through Tor Browser, is that censorship events would now require a Tor Browser release just to push new rules out to people. Publishing new Tor Browser releases is not a simple task, and enabling adversaries to force Tor Browser releases by tweaking their censorship systems seems like a cute way to DDOS the Applications team. An alternate update channel is definitely necessary outside of periodic Tor Browser releases. #### Are Per-Country Entries Granular Enough? One could imagine highly localized censorship events occurring which require special settings that are not needed in the rest of the country. For instance, if there is a clearnet blackout in Minneapolis, would we want to pipe *all* of our US users through the same bridges? Seems like a potential scalability problem for countries with large populations. ## Determining User Location A user's location can be determined by accessing location services through the clearnet. Mozilla offers a such a service ( https://location.services.mozilla.com/ ) with a very simple HTTP interface. Prior to bootstrapping, Tor Browser can access the location service by temporarily enabling network DNS: - network.dns.disabled=false and making an exception for the location service URL to bypass the proxy by: - network.proxy.no_proxies_on="location.services.mozilla.com" The location service would send back a country code in a JSON object which we can use to look up appropriate bridge settings in our map described above. ### Problems So the functionality of this approach is pretty easy to implement: tweak some prefs, make an XMLHttpRequest, change the prefs back. One possible problem we may face is if censors start blocking Mozilla's location services. Maybe we should have a pool of location service providers to make this more difficult (though we would need to do the research and figure out how feasible this is from a cost perspective). It is also possible to add location service functionality to moat, though this would also be a bit of an engineering endeavor. If we move forward with Mozilla's location services, we will need to acquire an API key, but I would not expect this to be an issue. We will also need to make arrangements with them to surpass the current limit of 100,000 daily API requests ( see: https://location.services.mozilla.com/terms ) The big challenge here is engineering the right UX which maintains our users trust. I think we need to be very explicit with this convenience feature, and definitely not just have it silently happen in the background. Users should also be able to opt-out, and manually select their country for the purposes of getting the right settings out of the above mentioned map. It should be very difficult to accidentally enable this automatic lookup. This will likely require a fair bit of iteration on the about:torconnect page design and flow.

2 1

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

08 Jul '21

# Arti Report 1: 23 June through July 7 We started with a project kickoff meeting. We're planning to continue meeting every 2 weeks, making our meetings increasingly public, and posting them on youtube. We wrote up an announcement to explain what Arti is and why we're doing it. The [announcement](https://blog.torproject.org/announcing-arti) goes live on July 8; it's a good place to start if you're not already familiar with the project, or if you're looking for more helpful links. To get ready for future development, and check the state of our packages we put out an [0.0.0 release](https://crates.io/crates/arti) and uploaded it to crates.io. We found a couple of issues while doing so ([#129][ticket-129], [#130][ticket-130]). We want to switch as much new-feature development to Arti as we can. With that in mind, we're developing a set of guidelines for discouraging features in C -- especially features with the potential to destabilize our code. (See [#128][ticket-128].) We're trying a bottom-up approach here, starting by identifying what kinds of features we've done recently that maybe we should skip in the future. We had an excellent meeting with developers on various Zcash projects, to gather requirements, set expectations, and open lines of communication. Based on their suggestions, we opened a set of new tickets to work on. ([#132][ticket-132] [#133][ticket-133] [#134][ticket-134] [#135][ticket-135] [#136][ticket-136] [#137][ticket-137] [#138][ticket-138] [#139][ticket-139] [#140][ticket-140]) In terms of new code written, things have been a bit slow: we're still ramping up, and a lot of folks take vacations in the summer. We [revised our asynchronous runtime backend][ticket-129] based on issues we found while uploading our packages. More recently, I've started working on an [implementation][ticket-57] of Tor's [circuit timeout inference][cti] code, which is necessary for good performance and security. ## Next steps In our next couple of weeks, I hope we get a first cut at our circuit timeout code finished and working, and figure out a reasonable initial solution for our [persistence needs][ticket-59]. We'll also be ramping up on implementations for [guard nodes][ticket-58] and [stream isolation][ticket-73], both of which are necessary for security. [ticket-57]: https://gitlab.torproject.org/tpo/core/arti/-/issues/57 [ticket-58]: https://gitlab.torproject.org/tpo/core/arti/-/issues/58 [ticket-59]: https://gitlab.torproject.org/tpo/core/arti/-/issues/59 [ticket-73]: https://gitlab.torproject.org/tpo/core/arti/-/issues/73 [ticket-128]: https://gitlab.torproject.org/tpo/core/arti/-/issues/128 [ticket-129]: https://gitlab.torproject.org/tpo/core/arti/-/issues/129 [ticket-130]: https://gitlab.torproject.org/tpo/core/arti/-/issues/130 [ticket-132]: https://gitlab.torproject.org/tpo/core/arti/-/issues/132 [ticket-133]: https://gitlab.torproject.org/tpo/core/arti/-/issues/133 [ticket-134]: https://gitlab.torproject.org/tpo/core/arti/-/issues/134 [ticket-135]: https://gitlab.torproject.org/tpo/core/arti/-/issues/135 [ticket-136]: https://gitlab.torproject.org/tpo/core/arti/-/issues/136 [ticket-137]: https://gitlab.torproject.org/tpo/core/arti/-/issues/137 [ticket-138]: https://gitlab.torproject.org/tpo/core/arti/-/issues/138 [ticket-139]: https://gitlab.torproject.org/tpo/core/arti/-/issues/139 [ticket-140]: https://gitlab.torproject.org/tpo/core/arti/-/issues/140 [cti]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/path-spec.txt#…

1 0

Build HS Circuit
by David Willis 27 Jun '21

27 Jun '21

Hi I'm doing a research project into onions and I'm trying to add a control port command to build a HS circuit. I see EXTENDCIRC can create normal circs, but how would I modify it a to build a HS circuit? Assuming I've already HSFETCHed it. I don't wait to initiate a socks request, just build the circuit and wait. It isn't quite clear to me where in the code base onion circuits are built or how, and how to initiate one. Would be grateful even for high-level instructions. Thanks David University of Singapore Sent with [ProtonMail](https://protonmail.com/) Secure Email.

1 0