August 2024 - 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

Proposal for a New Web App to Configure Tor Nodes
by Alessandro Greco 30 Aug '24

30 Aug '24

Hello everyone, I have been thinking about creating a web app that generates a script to configure a Tor node based on the settings defined by the user. Let me explain a bit further. This web app could work either entirely on the client side using JavaScript or on the server side. I believe a client-side-only approach is preferable because it avoids handling user data in any way and reduces the risk of man-in-the-middle attacks, although it doesn't completely eliminate it. The main use case would be for a user who wants to contribute by configuring a Tor node. Instead of manually writing all the various configurations — from downloading Tor to following the best practices after configuration — the user would simply need to select a series of options on a user-friendly page (user-friendly = easier setup => more wish to do it, which could realistically lead to more relays), download the auto-generated file, and run it with administrative privileges. I believe that developing such a web app could not only benefit the Tor network by encouraging the deployment of new nodes, but it could also be highly educational. Alongside the script to execute, a standard report could be generated to technically explain the function of each setting. Of course, there would be a standard section allowing for basic relay execution and an "advanced" section that opens up multiple functionalities for the user. I'm not sure if something like this already exists, but I think it could be very helpful. For instance, I often find myself scrolling through the manual to check for the latest updates applicable to the `torrc` file. With this web app, we could also create a "latest updates" section. This is just my rough idea, and if it proves useful not just for me but for the rest of the community as well, we could consider structuring a development project around it. Best regards, Aleff. --- Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get&search=0x7CFCE404A2168C85 Join to support: - Free Software Foundation! (my.fsf.org/join?referrer=6202114) - Electronic Frontier Foundation! (eff.org) - Tor-Project (torproject.org) - Signal (signal.org)

5 6

terminology explaination: identifier.
by eff_03675549＠posteo.se 27 Aug '24

27 Aug '24

Hi, On the following URL : http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/stats… the quote: *All per-graph statistics files are available for download via an URL of the form:* *https://metrics.torproject.org/identifier.csv* Remains ambiguous to me... *object of this email: *What is an /identifier/ ? Do the author imply the Nickname / Fingerprint ?... Do they imply the |KP_relayid_ed| that requires specific relay permission when the mere fingerprint is safer ?... *Would you kindly increment the torproject webpage with an example (or a set of examples) @ *http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/stats.html Cheers, Carlos.

2 1

Cancel
by tj 21 Aug '24

21 Aug '24

Sent from my iPhone

2 1

txtorcon 24.8.0
by meejah 20 Aug '24

20 Aug '24

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I'm gruntled to announce txtorcon 24.8.0 with the following changes: * Fix (test) issues with Twisted 24.7.0 (https://github.com/meejah/txtorcon/pull/400) * Remove usage of "six" (https://github.com/meejah/txtorcon/issues/395) from https://github.com/a-detiste txtorcon is an implementation of the "control-spec" for Tor using the "Twisted" networking library. This is the library to use if you want to write event-based software (including asyncio; interop is possible) in Python that uses the Tor network as a client or a service (or to integrate Tor support into existing Twisted-using applications). You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/24.8.0 https://github.com/meejah/txtorcon/releases/tag/v24.8.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 f790ab645a43a801ec68402467c15b2c816b6d16d93b36b89eed9ee9d17cc51f dist/txtorcon-24.8.0.tar.gz d3d0871a19c2ecaaae9e2c13b302a78b169048f5a3c2051069a2ea6ae44232c7 dist/txtorcon-24.8.0-py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCgAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAmbE8TQRHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaaeMTggAzkQ81pbZEN149nyR08zFzj2/oXWj5RzH huB4UDYmPTkzT7YvyI1e7CbcavLU7VEpcJCtEvFHsVx4PNG9cwc/Bd0/M8w0YVKM bNsijPX+d4SGZSL3rVwzKoMDPo6mm1fUiDgWFVZqqZ5PUagFKF7/iTvKShq4AVBe kwDJa2eiku3UDXcNRtbNtp+xxzrUIK5TcaUImeEXHIiQxsQJNbaL492FQXxYY2sM CFnGKH7QYkyQ8iFkVvqO7yaVI7oB1rFvD9FLrZXPHN+W2MIBG7ncfROs6LuBQQRC SuC+audP7Rbuf4uZp5RpdxQTkV2+k8L5mfAdu+k/WiihnsVoX1owdA== =wCIY -----END PGP SIGNATURE-----

1 0