September 2023 - tor-dev - lists.torproject.org

When RFC 7686 and transparent proxies collide
by Matt Jolly 28 Sep '24

28 Sep '24

Hello Everyone, I recently inadvertently opened a much larger can of worms than I'd intended when fixing a bug reported downstream where cURL would, when configured with certain DNS backends, fail to resolve .onion addresses. https://bugs.gentoo.org/887287 After doing some digging I discovered that the c-ares library was updated in 2018 to intentionally fail to resolve .onion addresses in line with RFC 7686, and another reported 'Bug' in cURL for leaking .onion DNS requests: https://github.com/c-ares/c-ares/issues/196 https://github.com/curl/curl/issues/543 I took the obviously sane and uncontroversial approach of making sure that cURL would always behave the same way regardless of the DNS backend in use, and that it would output a useful error message when it failed to resolve a .onion address. Unfortunately, this has made a lot of people very angry and been ~~widely regarded as a bad move~~panned by a small subset of downstream cURL users: https://github.com/curl/curl/discussions/11125 https://infosec.exchange/@harrysintonen/110977751446379372 https://gitlab.torproject.org/tpo/core/torspec/-/issues/202 I accept that, in particular, transproxy users are being inconvenienced, but I also don't want to go back to 'cURL leaks .onion DNS requests _sometimes_'. As a career sysadmin and downstream bug triager: this is the stuff that keeps me up late at night. Quite literally, far too often. I have found, however that the downstreams that I expected to be inconvenienced most (Whonix and Tails) simply use socks: https://github.com/Kicksecure/sdwdate/commit/5724d83b258a469b7a9a7bbc651539… https://github.com/Kicksecure/tb-updater/commit/d040c12085a527f4d39cb1751f2… https://github.com/Kicksecure/usability-misc/blob/8f722bbbc7b7f2f3a35619a5a… https://gitlab.tails.boum.org/tails/tails/-/issues/19488 https://gitlab.tails.boum.org/tails/tails/-/merge_requests/1123 I've asked in the Tor Specifications issue (inspired by Silvio's suggestions), and in the cURL issue, but I seem to be getting nowhere and the impacted users are clamouring for a quick band-aid solution, which I feel will work out worse for everyone in the long run: >How can client applications (safely): > >1.discover that they're in a Tor-enabled environment >2.resolve onion services only via Tor in that circumstance >3.not leak .onion resolution attempts at all > >Right now, not making these requests in the first place is the >safest (and correct) thing to do, however inconvenient it may be. >Rather than immediately trying to come up with a band-aid approach >to this problem, a sane mechanism needs to be implemented to: > >1.prevent each application from coming up with their own solution >2.prevent inconsistency in .onion resolution (i.e. no "oh it only >leaks if DO_ONION_RESOLUTION is set") >3.provide a standardised mechanism for applications that want to be Tor >aware to discover that they're in a Tor-enabled environment. I'm not particularly attached to that last point, but it's worth discussing. On a related note: -is the use of a transparent proxy recommended? -is there a sane alternative that involves as minimal configuration as possible for these users? I'm not sure what the best way forward is here, but I'm hoping that actual Tor developers might have a useful opinion on the matter, or at least be able to point me in the right direction. Thanks for your time, Cheers, Matt

7 9

funion: A Tor Client in Elixir
by Emil Engler 21 Sep '23

21 Sep '23

Hello Tor hackers, I just want to announce "funion", a Tor client implementation in Elixir which has been my primary side-project from March 2023 to August 2023. I began this project as an exercise in order to understand both, the Tor protocol and Elixir, a little bit better. Choosing Elixir came to my mind after watching a Computerphile video[1] introducing Erlang. After watching it, I concluded that Tor's hierarchy of connections -> circuits -> streams fits in very well -- which it actually does. Currently, the implementation is capable of creating streams across several hops with the ability of sending and receiving data. The implementation has a size of roughly 3500 LOC. A very neat feature is that each connection is a dedicated process having the circuits as dedicated child processes and the streams as dedicated grandchild processes respectively. This design leads to some very nice benefits, including the fact that only the circuit processes hold the cryptographic keys used in communication (except the TLS keys). Keep in mind however that it still lacks many features, most notably support for the directory protocol, resulting in the necessity of hard-coding each OR with the keys extracted manually from the consensus. I am not sure if I will find the time to continue hacking on this though, but it has been a very fun and refreshing experience so far. The Elixir code might not be the most beautiful out there, as this was my first project in this language. I do not consider this to be anything near production ready. Beside this, I purposely decided to ignore certain practices common in cryptographic applications (such as overwriting sensitive keys with zeros) for the sake of simplicity, as my primary intention was to understand the Tor protocol, not to write a tool that allows secure and anonymous communication across the internet. If you seriously depend on anonymity: DO NOT USE THIS! The repository can be found here: https://github.com/emilengler/funion A talk given at BornHack 2023 talking about the internals and pitfalls can be found here: https://media.ccc.de/v/bornhack2023-56123-funion-a-tor-client-i My dedications go to the following people who have helped me dealing with understanding various internals of Tor, be it direct or indirect: - Roger Dingledine - Alexander Færøy - Ian Jackson - Nick Mathewson - The Talla Authors - trinity [1]: https://www.youtube.com/watch?v=SOqQVoVai6s

1 0

Automating dependency updates in Tor
by micah anderson 17 Sep '23

17 Sep '23

Tor has been undertaking security audits of code that we've been changing. Security audits are a good thing! They uncover blind spots, peel back assumptions, and present us with ways to improve our overall security posture. We intend to publish the results of the two that we've done recently, and commit to publishing every one we undertake - stay tuned. The first audit we did recently was a great success! The auditors remarked that although the scope was large, the number of issues uncovered was low, and that Tor in general adopts an admirably robust and hardened security posture and sound design decisions: "[Tor's] code was written to a first-rate standard and conformed to secure coding practices ... adopt[ing] highly-advanced and deliberately security focused building processes ... all which contribute towards considerable defense-in-depth security posture". One of the issues that came up was the overall lack of automated resiliency in our software supply chain. What does this mean? That means several dependencies in our software were outdated. Why were these outdated? Because we lack the automation. Tracking dependencies manually is difficult, you need to manually search for those updates individually (although some package managers offer automated functionality), it can be difficult to handle So now we have a solution, Renovate: a highly configurable system for dependency update automation. It scans your software, discovers dependencies, automatically checks to see if an updated version exists, and helps you by submitting automated pull requests. It is an open source project that we are self-hosting on our gitlab (its like 'dependabot' if you know that). A number of Tor projects are using it already, please consider using it for your project! Its very simple to use, and there is no harm in giving it a try. We are still trying this out, so your feedback[2] is important for how to move forwards. Ideally, we will have this problem solved automatically for all of our projects, but lets make sure things work well for everyone first. How do I use it? ----------------- To have renovate work on your gitlab project, you simply have to invite the 'renovate-bot' user (its a bot!) to your project (with the `Developer` access level), and then wait for it to do its work. Next time it runs, it will open an "Onboarding" issue[0], to get you started. The first time it runs, there may be a number of dependencies that need updating, which will result in a MR for each[1]. That could be overwhelming, but after the initial wave, things will calm down. Simply review the MR and merge it if it makes sense (making any code adjustments necessary). If you don't want that MR to happen, simply close it, and Renovate will stop bugging you about it. How does it work? ----------------- There is a project in our gitlab[2], which has a scheduled CI that runs every 30 minutes. When it runs, it looks to see what projects have the gitlab bot user 'renovate-bot' as a member, with 'developer' level access. For each of those projects, it then scans the project for any dependencies that need updating, and will open MRs to update those out-of-date dependencies (triggering CI builds). Your project must also have a CI that is being tended to, so that it runs and succeeds. I want to change its behavior ----------------------------- Renovate is highly configurable. You can decide what you do, and do not, want from Renovate. There are knobs for practically everything[3]. Renovate has a default[4] set of configurations that we've set organization-wide, you can override those in your project, and set any other configuration options[5] you might want. How to give feedback, ask questions, etc. ----------------------------------------- If you are looking for help, have questions, or want to give some feedback on global defaults or other aspects that could be improved, please file an issue[1]! 0. eg. https://gitlab.torproject.org/tpo/core/onionmasq/-/merge_requests/101 1. eg. https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/merge_requests/151 2. https://gitlab.torproject.org/tpo/tpa/renovate-cron/ 3. https://docs.renovatebot.com 4. https://github.com/renovatebot/renovate/blob/main/docs/development/configur… 5. https://docs.renovatebot.com/getting-started/use-cases/

1 0