- tor-dev - lists.torproject.org

ORB - Onion Reply Block
by Stefan Claas 03 Jun '25

03 Jun '25

Hi gentlemen, I would like to introduce you to pluto an smtp relay wich is using ORBs and would like to know your thoughts. https://githib.com/Ch1ffr3punk/pluto I post it here, because on the regular Tor forum it did not yet received any attention, in form of replies. Best regards Stefan

1 1

Proposal 364: CreateOnehop handshake to replace CREATE_FAST
by Nick Mathewson 07 May '25

07 May '25

https://spec.torproject.org/proposals/364-create-onehop.html This proposal describes a successor to CREATE_FAST that permits circuit handshake extensions. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! -- Nick

1 0

Proposal 363: Required/recommended protocols for onion services
by Nick Mathewson 07 May '25

07 May '25

https://spec.torproject.org/proposals/363-required-protovers-and-hs.html This proposal describes an enhancement to how we use subprotocol versioning in the consensus to advertise recommended and required subprotocols for running and connecting to onion services. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! peace, -- Nick

1 0

Proposal 362: Update onion service proof-of-work control loop
by Wesley Aptekar-Cassels 06 May '25

06 May '25

https://spec.torproject.org/proposals/362-update-pow-control-loop.html This proposal suggests a new algorithm for onion services to use to select the suggested effort value for the proof-of-work algorithm. The existing algorithm has some weaknesses, mostly stemming from the fact that the same request sent at different points in time might have different effects on the new suggested effort. The proposed algorithm is based in a more fundamental analysis of the goals of the control loop. Please feel free to open tickets on GitLab, discuss in the tracking ticket, torspec#329, or discuss here. :w

1 0

Proposal 361: Onion Association SANs in Certificates (OASIC)
by Micah Anderson 06 May '25

06 May '25

https://spec.torproject.org/proposals/361-oasic.html This proposal describes Onion Association standardization, authenticated by TLS certificates. It specifies how this association is encoded in the certificate's Subject Alternative Name (SAN) field, providing meaningful SAN-based Onion Association authentication. This proposal was written by Paul Syverson, I'm announcing it on his behalf. Feel free to open tickets on gitlab, discuss here, or also on the Tor Forum. -- Micah Anderson (he/him) Director of Engineering The Tor Project, Inc. <https://torproject.org>

1 0

Proposal 361: Onion Association SANs in Certificates (OASIC)
by Micah Anderson 06 May '25

06 May '25

https://spec.torproject.org/proposals/361-oasic.html This proposal describes Onion Association standardization, authenticated by TLS certificates. It specifies how this association is encoded in the certificate's Subject Alternative Name (SAN) field, providing meaningful SAN-based Onion Association authentication. This proposal was written by Paul Syverson, I'm announcing it on his behalf. -- Micah Anderson (he/him) Director of Engineering The Tor Project, Inc. <https://torproject.org>

1 0

[GSoC 2025] Graph-Based Relay Partitioning – Proposal and Repository
by Valentina Schiavon 21 Apr '25

21 Apr '25

Dear Tor team, I recently submitted a proposal to Google Summer of Code 2025 titled "Graph-Based Analysis of Relay Partitioning in the Tor Network", focused on detecting partitioning patterns through graph data science techniques. Although the project is still in its proposal phase, I have already created a GitHub repository( https://github.com/valentinaschiavon99/tor-relay-partitioning-gsoc2025) where I’m documenting the structure, early diagrams, and test notebooks. I'm reaching out in case any of you have suggestions or would like to point me toward related work, potential pitfalls, or early contributions I could start working on (e.g., documentation or testing). Thank you very much for your time and for the opportunity to contribute to such an impactful project. Best regards, Valentina Schiavon Business Informatics student @ AAU Klagenfurt ,Austria https://www.linkedin.com/in/valentinaschiavon1/ https://github.com/valentinaschiavon99 valentinaschiavon99(a)gmail.com

1 0

Proposal 360: Limiting HSDesc size and amplification
by Nick Mathewson 09 Apr '25

09 Apr '25

https://spec.torproject.org/proposals/360-hsdesc-len-limit.html This proposal describes a mechanism for preventing some kinds of traffic-flooding attacks by HSDirs. It's based on some of Mike Perry's work on Proposal 349. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! best wishes, -- Nick

1 0

Proposal 359: Counter Galois Onion, Updated
by Nick Mathewson 09 Apr '25

09 Apr '25

https://spec.torproject.org/proposals/359-cgo-redux.html This proposal instantiates a new approach for encrypting relay cells on circuits, to prevent certain kinds of tagging attacks, to improve forward secrecy, and more. It is based on research by Jean Paul Degabriele, Alessandro Melloni, Jean-Pierre Münch, and Martijn Stam. You can read their paper at https://eprint.iacr.org/2025/583 This is important and subtle; I'd appreciate any feedback, especially from cryptographers. I plan to start implementing this quite soon, on the theory that, even if there _are_ flaws, it is very unlikely to be _worse_ than our current malleable relay encryption. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! cheers, -- Nick

1 0

can tor use secondary groups to read FamilyKeyDirectory?
by nusenu 09 Apr '25

09 Apr '25

Hi, given the following example, tor fails to access the familykeydir folder. familykeydir has the following permissions: drwxr-x--- 2 root tor_reader id _tor uid=996(_tor) gid=993(_tor) groups=993(_tor),994(tor_reader) Is tor able to use secondary groups? When using sudo to switch to user _tor manually, it is possible to read files in that folder without problems. The problem does not happen when _tor's primary group is set to 'tor_reader'. Tested on debian. kind regards, nusenu -- https://nusenu.github.io

3 3

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

[tor-project] Reminder: mailman 3 upgrade imminent (TPA-RFC-71)
by Antoine Beaupré 29 Oct '24

29 Oct '24

Hi, As mentioned in early October, we're in the process of upgrading our main mail server, which includes upgrading to the shiny new Mailman 3 platform. We have, right now, a prototype mailman 3 server available at: https://lists-01.torproject.org/ It's hidden behind the usual "trivial" authentication (ask us on IRC if you don't remember what it is), but should otherwise work normally. I'm going to start by migrating the TPA mailing list and we'll be testing this for a couple of days, but, next week, I'll start migrating the other mailing lists (including this one!). If people want to jump in front of that train early and be part of the beta testers, then by all means I'm happy to have your mailing list be part of the early adopters. Be warned that Mailman 3 is a significant upgrade from Mailman 2. There are some great things (like unified authentication), and some less great things (like a more complex design and "shinier" web interface that might not be everyone's taste). As a reminder, we're doing this upgrade a little rushed because the main mail server is now unsupported for security upgrades. See the details of the proposal here: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-71-emerge… ... with the milestone tracking actual work issues in: https://gitlab.torproject.org/groups/tpo/tpa/-/milestones/16 (Sorry for cross-posting this, but this seems like it warrants wider distribution. As a rule of thumb, I selected mailing lists with public archives that had posts in October 2024, removing duplicates like anti-censorship-team and -alerts. I also suspect many of those mailing lists will refuse my message because I'm not subscribed, but I will have tried. :)) Phew! a. -- Antoine Beaupré torproject.org system administration _______________________________________________ tor-project mailing list tor-project(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project

1 0

Sharing Circuits Between Onion Servers and Clients
by stifle_savage042＠silomails.com 26 Oct '24

26 Oct '24

Hi all, I want to promote some recent work of mine in the hope that someone here will find it interesting or useful. In my most concise language, it is a "decentralized, asynchronous entropy generator protocol." I've made a somewhat complete demo implementation so far. Here's the repository: https://github.com/devnetsec/rand-num-consensus. The integrity of the entropy can only be compromised if all nodes in the ring are malicious and coinciding. Currently, a Tor client cannot anonymously connect to an onion service by directly contacting the rendezvous point, because that relay could have been chosen maliciously by the onion server. I wager that a scheme like this could enable onion servers and clients to share the same circuit. Both parties would have a guarantee that their relays were chosen randomly. The most similar solution I could find to this was in the TorCoin paper, but it appears to require a more complicated zero-knowledge proof. If there is serious interest in this, I'd be willing to write a proposal draft. Besides implementation difficulty, is there any outstanding flaw in this idea? Best Regards, Dylan Downey [devnetsec]

4 6

Proposal: Handling Complex DNS Traffic for VPN usage in Tor
by Alexander Færøy 21 Oct '24

21 Oct '24

Hello! Micah and I worked on this as part of the P101 work for the VPN. Some of the work that Q is looking into as part of its involvement with the Onion Services Working Group may impact some of these items. Cheers, Alex --- snip --- ``` Filename: XXX-complex-dns-traffic-for-vpn.md Title: Handling Complex DNS Traffic for VPN usage in Tor Authors: Alexander Færøy and Micah Anderson Created: 2024-05-22 Status: Open ``` [[_TOC_]] # Introduction ## Background As part of our work building a prototype for a VPN client that uses the Tor network, we have investigated the need for more modern DNS handling within the Tor network. Presently, Tor exit nodes support hostname resolution and reverse DNS lookups for both IPv4 and IPv6 addresses. Reverse DNS queries are handled by sending a `RELAY_RESOLVE` cell containing an `in-addr.arpa` hostname, with successful responses returning a hostname in the reply cell. Initially, a broader set of features was considered. However, with the introduction of proposal #348 (UDP Application Support in Tor), we have been able to conduct more direct experiments with the required DNS types on the Android platform, utilizing both TCP and UDP resolvers. ## Objective This proposal aims to expand Tor's DNS resolution capabilities by supporting a broader range of DNS request types. Additionally, we will examine the potential impacts of this enhancement on various aspects of the Tor network. ## Audience This proposal is largely designed for users who interact with Tor via the `DNSPort` or through Onionmasq's virtual DNS proxy. In this context, the additional round-trip time for DNS requests and responses is not a significant concern, as it is an expected characteristic of the VPN environment. ## Compatibility Considerations A key requirement of this proposal is to maintain compatibility with common DNS debugging tools such as `dig` and `drill`. Users should be able to continue using these tools to troubleshoot the DNS layer in Tor, whether they're connecting through Tor's `DNSPort` or Onionmasq's virtual VPN DNS server. # New DNS Records This section outlines the additional DNS record types we propose to incorporate into the Tor protocol's DNS layer. Implementing these changes will require updates to the "Remote hostname lookup" section (6.4) of the `tor-spec.txt` document. Specifically, the new types need to be added in addition to the response format. It's important to note that until fragmented cells are supported in C Tor, responses may be truncated due to Tor's cell size limitations. ## HTTPS and SVCB Records In RFC 9460, the IETF defines the SVCB and HTTPS DNS resource records (RR). These records are important in the VPN context to allow web application authors to both provide alternative ports to connect to for HTTP resources, but more importantly, it can be used together with modern HTTP implementation APIs to send pre-flight requests to determine if an end-point supports HTTP/3 (HTTP-over-Quic/UDP) as an alternative to HTTP-over-TCP. This is needed for additional usage of the UDP feature defined in proposal #348. Although the wire format is defined in RFC 9460 section 2.2, Tor does not need to parse the wire format; it should simply propagate the response payload to the client. Tor is currently limited to the 509 bytes per cell, which may be insufficient for complex payloads. Until fragmented cells are supported network-wide, Tor SHOULD trim over-sized payloads to fit within the 509-bit limit. # Security Implications DNS represents a potential attack vector for adversaries seeking to cause harm to the Tor network. As we expand DNS capabilities, we must carefully consider and mitigate associated security risks. ## Denial of Service (DoS) Attacks A major risk involving DNS is Denial of Service attacks. In particular, amplification attacks are a powerful way where an adversary with relatively little effort and request size can cause an exit node to be flooded with significantly larger response sizes from its DNS provider, thus blocking its uplink with DNS responses instead of more useful traffic. While Tor's relatively conservative support of the DNS protocol has mitigated this risk, past DoS attacks have targeted exit nodes with flooding DNS requests. ## Amplification Attacks Because we are adding support for new types where the request-to-response ratio is different from the currently supported types (A, AAAA, and PTR), there is a potential for attackers to exploit these new record types to amplify their attacks more effectively. As such, we need to be cautious and implement feature toggles can be used to disable the ability to utilize certain record types, and keep track of the request-to-response ratio in the network. ## Mitigation Strategies It is important that when this proposal is implemented, that we ensure the following: 1. Monitoring and Metrics: We MUST implement Tor's internal MetricsPort features to keep track of both the request type, the request size, and the response sizes. This will allow us to analyze DNS request-to-response ratios together with the Exit node operator community and determine if some DNS types are more prone to abuse than others. We suggest the following records to be exposed via the MetricsPort (naming can be changed later): ``` dns_lookup_count{type=rr} = n dns_lookup_request_size{type=rr} = n dns_lookup_response_size{type=rr} = n ``` Where `rr` is all of A, AAAA, PTR, and SVCB/HTTPS. 2. Anomaly Detection: Network health SHOULD utilize these metrics to develop systems to detect unusual patterns in DNS request volume and implement automated alerts for potential attacks. 2. Feature Toggles: We MUST ensure that the directory authorities have the ability to disable specific DNS types globally in the network in case of catastrophic abuse of the feature. This can be done using consensus parameters. 3. Response Size Limits: We MUST enforce strict limits on DNS response sizes, especially for the new record types, and implement intelligent truncation for over-sized responses. 4. Rate Limiting: Consider implementing per-client and per-record-type rate limiting for DNS requests. Consider adaptive rate limiting based on network conditions and observed patterns. 5. Periodic Auditing: Regularly review and update security measures as new threats emerge. Conduct periodic testing focused on DNS-related vulnerabilities. # Implementation Recommendations 1. Phased Rollout: Introduce new DNS capabilities gradually, monitoring for abuse at each stage. 2. Configurable Limits: Allow node operators to set custom limits on DNS usage. 3. Fallback Mechanisms: Implement fallback to basic DNS functionality if abuse is detected. 4. Collaborative Defense: Engage with the Network Health and Community team for developing analysis, response and coordination with the Exit operator community. # External References 1. Cloudflare wrote a blog post of the usage of HTTPS records in https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-d… 2. PowerDNS already implemented automatic hints for SVCB records in their software. See: https://doc.powerdns.com/authoritative/guides/svcb.html#svc-autohints # Testing and Debugging Cloudflare has SVCB enabled on `blog.cloudflare.com` and `crypto.cloudflare.com`. Their record can be seen using: $ dig blog.cloudflare.com -t TYPE65 If you have `drill` installed with modern HTTPS/SVCB support, you can also query it with a nicer response using: $ drill HTTPS blog.cloudflare.com This should make it easier to test the feature. --- snip --- -- Alexander Færøy

1 0

Tor over QUIC
by Q Misell 11 Oct '24

11 Oct '24

Hi all, I know the discussion on how best to support UDP applications over Tor has dragged on for a long time, so I thought what better to do than to throw another item to bikeshed into the discussion :) On a more serious note I think running Tor over QUIC would provide several advantages - both for the current stream transport and for possible future datagram transports. On a technical level I don't think this would require huge changes to the Tor specification, circuit IDs map nicely to QUIC stream IDs, and datagram packets - whatever form they take - can be sent as QUIC datagram frames (c.f. RFC 9221). The primary advantage I see QUIC providing is the removal of head of line blocking. As Tor currently multiplexes everything over one TCP connection, a single dropped packet will delay all circuits and streams. This impacts bandwidth utilisation and makes Tor less than ideal for real-time applications. Given this it might make more sense to provide a mapping of Tor streams to QUIC streams rather than Tor circuits - but this is a minor technical detail to be worked out in any specification. Now, that's great and all, but is it secure? I think yes - although I haven't done an in depth analysis yet. QUIC is very resistant against de-anonymization by passive attackers - the only thing a passive observer can see is a cryptographically generated random connection ID. QUIC also provides in-built padding frames to protect against traffic analysis. The connection setup and handshake is protected by the usual TLS mechanisms (with a minimum version of TLS 1.3). We already know recent TLS versions to be almost bullet proof if used correctly, and TLS is already the base transport for Tor anyway. A read of the security considerations section of RFC 9000 seems to confirm that even an active attacker can at most cause a connection to fail. Another concern is this making Tor traffic stand out more. This is a very legitimate concern, however with the increasing deployment of HTTP/3 I don't think it will make Tor stand out against the background of HTTP/3 traffic, see: https://e.as207960.net/w4bdyj/uJdzhSHvRZOf5dPL I recognise this is a rather large project - and may not be worthwhile. I only expect this to be implemented in Arti, so deployment of Tor over QUIC in the real world will take at least until Arti is widely used. What are people's thoughts on this? Q ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively.

6 7

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