tor-dev October 2024

tor-dev@lists.torproject.org

12 participants
4 discussions

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev October 2024