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/196https://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/11125https://infosec.exchange/@harrysintonen/110977751446379372https://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/19488https://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
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)
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.
-----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.0https://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-----
