- tor-dev - lists.torproject.org

Call for comments on proposals 346, 354, and 358.
by Nick Mathewson 08 Apr '25

08 Apr '25

Hi, all! We're hoping to implement these proposals soon: https://spec.torproject.org/proposals/346-protovers-again.html https://spec.torproject.org/proposals/354-relaxed-restrictions.html https://spec.torproject.org/proposals/358-unified-handshake-extensions.html Barring major objections, we're going to change their state from "Open" to "Accepted" in about a week. If anybody would like to comment, either here or on the bugtracker (https://gitlab.torproject.org/tpo/core/torspec/) that would be great! best wishes, -- Nick

1 0

Proposal 358: Unifying circuit handshake extensions
by Nick Mathewson 27 Mar '25

27 Mar '25

https://spec.torproject.org/proposals/358-unified-handshake-extensions.html This proposal suggests that we should unify the EXT_FIELD_TYPE namespace, which is currently shared between CREATE2 and INTRODUCE2 messages. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! cheers, -- Nick

1 0

Proposal 357: Circuit key exporters: A better way to use KH
by Nick Mathewson 27 Mar '25

27 Mar '25

https://spec.torproject.org/proposals/357-circ-key-exporters.html This proposal declares a new way to use the "KH" output of our circuit handshake protocol in the future, to avoid the possibility of creating cross-protocol attacks. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! cheers, -- Nick

1 0

Proposal 356: Increasing netdoc strictness not considered (very) harmful
by Nick Mathewson 27 Mar '25

27 Mar '25

https://spec.torproject.org/proposals/356-desc-parsing-variance.html This proposal explains why we will not, in the future, generally worry about protocol changes that make strings that were formerly accepted as network documents become rejected in future versions. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! cheers, -- Nick

1 0

Proposal 355: Options for postquantum circuit extension handshakes
by Nick Mathewson 27 Mar '25

27 Mar '25

https://spec.torproject.org/proposals/355-revisiting-pq.html This proposal updates earlier proposals about postquantum cryptography in Tor circuit extensions, to handle changes in Tor and the PQ landscape since those proposals were written. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! cheers, -- Nick

1 0

Make torsocks mutli-arch ready
by Hefee 27 Mar '25

27 Mar '25

Hey, in Debian we want to enable mutli-arch support for torsocks. To be able to run different binaries of different archs. We already splitted libtorsocks into own package, so you can now install e.g.: torsocks:amd64, libtorsocks:amd64, libtorsocks:i386, wget:i386 But the torsocks script loads the libtorsocks by full path, so torsocks wget will fail, as it loads the amd64 variant only. ldconfig has this nice feature to find the correct library, if you only add the name and that the library is in default search dir or you add a conf file in / etc/ld.so.conf.d/. Using just the libname makes the "safty" check `! -e "$SHLIB"` fail, as $SHLIB, is only the libname in our case. Can you have a look at the patch[1], if you think it is safe to ship this? [1] https://salsa.debian.org/pkg-privacy-team/torsocks/-/blob/master/debian/ patches/0004-Make-torsocks-multi-arch-foreign-compatible.patch The issue I see is this: If arch from executable and the corresponding libtorsocks is not installed, only a Error is printed, but still the executable is executed without routing trough tor. The disabled check in torsocks could somehow catch this, if we would knew the arch of the executable in advanced correctly (which we don't, so far). If we can make sure, that LD_PRELOAD would stop executing, if the library cannot be found. e.g. I install libtorsocks:amd64 and wget:i386 I get: $wget -O- -4 icanhazip.com XX.230.187.XX $ torsocks wget -O- -4 icanhazip.com ERROR: ld.so: object 'libtorsocks.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. [...] XX.230.187.XX [...] (installing libtorsocks:i386 fixes this) On the other side, this does not got worse; currently torsocks will print a different error see #902792 but still execute the binary without tor. So this safety check doesn't help here (and btw. installing libtorsocks:i386 does not fix this issue by itself you also need to call /usr/bin/i386-linux-gnu- torsocks). #902792 https://bugs.debian.org/cgi-bin/902792 Regards, hefee

2 4

Proposal 354: Relaxing Path Restrictions in Arti
by Mike Perry 05 Mar '25

05 Mar '25

https://spec.torproject.org/proposals/354-relaxed-restrictions.html This is a proposal to simplify the usage of Family, Subnet, and custom path restrictions in Arti, so that clients don't reveal information about their Guards or Bridges by way of which relays they use, or don't use, in circuits. The meat of the proposal is that Arti's circuit path construction will satisfy the following rules: 1. Choose the Exit, HSDir, IP, or RP without considering restrictions 2. Choose Guard, Bridge, and Vanguards hops without considering restrictions 3. Choose any remaining middle nodes such that subnet, relay family, and user family restrictions apply with respect to the next hop (Exit, HSDir, IP, or RP) 4. Reject any resulting circuits with A-A and A-B-A sub-paths 5. If building a conflux leg: Reject any circuits that share relays with the other conflux leg(s) in the current conflux set. This simplifies path construction logic and avoids many pitfalls and information leaks caused by restriction use. These pitfalls and information leaks are documented in the proposal. The spec ticket in gitlab will remain open for comment until April 2, 2025: https://gitlab.torproject.org/tpo/core/torspec/-/issues/307 Comment here is also acceptable. -- Mike Perry

1 0

About the key derivation algorithm used in the Control Port password authentication
by techmetx11 04 Mar '25

04 Mar '25

Although several parts of Tor have been redesigned and upgraded over many years, the algorithm for the HashedControlPassword still remained the same. It still uses SHA-1 as the basis of the OpenPGP S2K algorithm, despite the fact that the algorithm has long-since been obsolete by newer and better hashing algorithms (on top of it, has had some practical collision attacks[1]). This is made worse by the fact that the S2K algorithm is not iterative (in the sense of recursive hashing), but rather repeats the salt+password many times in the hash digest until it reaches a certain amount of bytes. Theoretically, an attacker can expose this to autheticate into a Tor Control Port without having to know the password. Are there any plans to revamp the algorithm for newer Tor versions? [1]: https://shattered.io/

2 1

Metadata Cleaner is looking for a new co-maintainer
by intrigeri 23 Jan '25

23 Jan '25

Hi, Many files contain hidden data, or metadata: * JPEG and other image files often contain information about where a picture was taken and which camera was used. * Office documents often contain information about their author, the date and time the document was created, as well as the complete changes history. To help you remove those metadata, Tails include Metadata Cleaner, a tool to remove metadata in a wide range of file formats: https://metadatacleaner.romainvigier.fr/ It is also available in Debian and on Flathub. Unfortunately, the future of Metadata Cleaner is compromised: it has no active maintainer anymore. The codebase is healthy and up-to-date: as far as we know, no urgent code change is required at the moment. Nevertheless, a widely used free software project needs active maintenance work, for example to triage issues reported by users, to review contributions, to maintain healthy relationships with upstream & downstreams, and to fix in a timely manner any critical bug or security vulnerability that might be discovered. And sooner or later, deeper code work might be necessary for the tool to keep working with newer versions of its dependencies. So we need at least 1 new co-maintainer to take over this duty. Metadata Cleaner is a Python GTK application built on top of mat2, which does the heavy lifting of metadata cleanup. Fun fact: mat2 originates from MAT, which was created in 2011 as part of a Tails/Tor GSoC project (https://0xacab.org/jvoisin/mat2) "Metadata Cleaner amplifies the usefulness of mat2 by making it usable by the users who need it the most, with a familiar graphical user interface. It nicely complements mat2-web, because it does not require trusting an online service with one's metadata: with Metadata Cleaner, the processing happens locally. As such, it's a key component of the ecosystem that enables users to work safely with sensitive documents." says Julien Voisin, author of MAT and mat2, who volunteered to be the other co-maintainer. If you want to become a co-maintainer of Metadata Cleaner, please get in touch at mat-dev(a)boum.org (public mailing list). Thanks in advance, and many thanks to Romain Vigier for creating Metadata Cleaner! -- intrigeri, for the Tails Team jvoisin, mat2 developer

1 0

New BUG() call and stack-trace seen in the wild on 0.4.8.13 exit relay.
by George Hartley 16 Nov '24

16 Nov '24

Hi, I noticed the following when checking journalctl logs from Tor: > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] tor_bug_occurred_(): Bug: src/core/or/relay.c:2354: connection_edge_package_raw_inbuf: Non-fatal assertion !(conn->base_.marked_for_close) failed. (on Tor 0.4.8.13 )Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: Tor 0.4.8.13: Non-fatal assertion !(conn->base_.marked_for_close) failed in connection_edge_package_raw_inbuf at src/core/or/relay.c:2354. Stack trace: (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/bin/tor(+0x1c8c5d) [0x62048e493c5d] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/bin/tor(+0x94325) [0x62048e35f325] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/bin/tor(+0x4335f) [0x62048e30e35f] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/bin/tor(+0x11afa6) [0x62048e3e5fa6] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/bin/tor(+0x10e8a2) [0x62048e3d98a2] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/lib/libevent-2.1.so.7(+0x22b42) [0x7488c6f57b42] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/lib/libevent-2.1.so.7(event_base_loop+0x4ff) [0x7488c6f593af] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/bin/tor(+0xd3da) [0x62048e2d83da] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/bin/tor(+0xa947) [0x62048e2d5947] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/lib/libc.so.6(+0x25e08) [0x7488c6527e08] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/lib/libc.so.6(__libc_start_main+0x8c) [0x7488c6527ecc] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/bin/tor(+0xba25) [0x62048e2d6a25] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] connection_edge_package_raw_inbuf(): Bug: called on conn that's already marked for close at src/core/or/relay.c:1870. (on Tor 0.4.8.13 ) I didn't have the time to actually look at the function in question, and I also left my Gitlab authenticator device (fully encrypted) at a friends / colleagues place, otherwise I would have likely opened a Gitlab ticket, given I figured out the actual bug behind it, if any. However, as I am unable right now and also not at my usual workplace, I included tor-dev in the recipients. Thanks. -GH

1 0