- tor-dev - lists.torproject.org

funion: A Tor Client in Elixir
by Emil Engler 21 Sep '23

21 Sep '23

Hello Tor hackers, I just want to announce "funion", a Tor client implementation in Elixir which has been my primary side-project from March 2023 to August 2023. I began this project as an exercise in order to understand both, the Tor protocol and Elixir, a little bit better. Choosing Elixir came to my mind after watching a Computerphile video[1] introducing Erlang. After watching it, I concluded that Tor's hierarchy of connections -> circuits -> streams fits in very well -- which it actually does. Currently, the implementation is capable of creating streams across several hops with the ability of sending and receiving data. The implementation has a size of roughly 3500 LOC. A very neat feature is that each connection is a dedicated process having the circuits as dedicated child processes and the streams as dedicated grandchild processes respectively. This design leads to some very nice benefits, including the fact that only the circuit processes hold the cryptographic keys used in communication (except the TLS keys). Keep in mind however that it still lacks many features, most notably support for the directory protocol, resulting in the necessity of hard-coding each OR with the keys extracted manually from the consensus. I am not sure if I will find the time to continue hacking on this though, but it has been a very fun and refreshing experience so far. The Elixir code might not be the most beautiful out there, as this was my first project in this language. I do not consider this to be anything near production ready. Beside this, I purposely decided to ignore certain practices common in cryptographic applications (such as overwriting sensitive keys with zeros) for the sake of simplicity, as my primary intention was to understand the Tor protocol, not to write a tool that allows secure and anonymous communication across the internet. If you seriously depend on anonymity: DO NOT USE THIS! The repository can be found here: https://github.com/emilengler/funion A talk given at BornHack 2023 talking about the internals and pitfalls can be found here: https://media.ccc.de/v/bornhack2023-56123-funion-a-tor-client-i My dedications go to the following people who have helped me dealing with understanding various internals of Tor, be it direct or indirect: - Roger Dingledine - Alexander Færøy - Ian Jackson - Nick Mathewson - The Talla Authors - trinity [1]: https://www.youtube.com/watch?v=SOqQVoVai6s

1 0

Automating dependency updates in Tor
by micah anderson 17 Sep '23

17 Sep '23

Tor has been undertaking security audits of code that we've been changing. Security audits are a good thing! They uncover blind spots, peel back assumptions, and present us with ways to improve our overall security posture. We intend to publish the results of the two that we've done recently, and commit to publishing every one we undertake - stay tuned. The first audit we did recently was a great success! The auditors remarked that although the scope was large, the number of issues uncovered was low, and that Tor in general adopts an admirably robust and hardened security posture and sound design decisions: "[Tor's] code was written to a first-rate standard and conformed to secure coding practices ... adopt[ing] highly-advanced and deliberately security focused building processes ... all which contribute towards considerable defense-in-depth security posture". One of the issues that came up was the overall lack of automated resiliency in our software supply chain. What does this mean? That means several dependencies in our software were outdated. Why were these outdated? Because we lack the automation. Tracking dependencies manually is difficult, you need to manually search for those updates individually (although some package managers offer automated functionality), it can be difficult to handle So now we have a solution, Renovate: a highly configurable system for dependency update automation. It scans your software, discovers dependencies, automatically checks to see if an updated version exists, and helps you by submitting automated pull requests. It is an open source project that we are self-hosting on our gitlab (its like 'dependabot' if you know that). A number of Tor projects are using it already, please consider using it for your project! Its very simple to use, and there is no harm in giving it a try. We are still trying this out, so your feedback[2] is important for how to move forwards. Ideally, we will have this problem solved automatically for all of our projects, but lets make sure things work well for everyone first. How do I use it? ----------------- To have renovate work on your gitlab project, you simply have to invite the 'renovate-bot' user (its a bot!) to your project (with the `Developer` access level), and then wait for it to do its work. Next time it runs, it will open an "Onboarding" issue[0], to get you started. The first time it runs, there may be a number of dependencies that need updating, which will result in a MR for each[1]. That could be overwhelming, but after the initial wave, things will calm down. Simply review the MR and merge it if it makes sense (making any code adjustments necessary). If you don't want that MR to happen, simply close it, and Renovate will stop bugging you about it. How does it work? ----------------- There is a project in our gitlab[2], which has a scheduled CI that runs every 30 minutes. When it runs, it looks to see what projects have the gitlab bot user 'renovate-bot' as a member, with 'developer' level access. For each of those projects, it then scans the project for any dependencies that need updating, and will open MRs to update those out-of-date dependencies (triggering CI builds). Your project must also have a CI that is being tended to, so that it runs and succeeds. I want to change its behavior ----------------------------- Renovate is highly configurable. You can decide what you do, and do not, want from Renovate. There are knobs for practically everything[3]. Renovate has a default[4] set of configurations that we've set organization-wide, you can override those in your project, and set any other configuration options[5] you might want. How to give feedback, ask questions, etc. ----------------------------------------- If you are looking for help, have questions, or want to give some feedback on global defaults or other aspects that could be improved, please file an issue[1]! 0. eg. https://gitlab.torproject.org/tpo/core/onionmasq/-/merge_requests/101 1. eg. https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/merge_requests/151 2. https://gitlab.torproject.org/tpo/tpa/renovate-cron/ 3. https://docs.renovatebot.com 4. https://github.com/renovatebot/renovate/blob/main/docs/development/configur… 5. https://docs.renovatebot.com/getting-started/use-cases/

1 0

Prop#344: Prioritizing Protocol Information Leaks in Tor
by Mike Perry 23 Aug '23

23 Aug '23

As part of Sponsor 112, Tor has an objective to address covert channels that malicious relays can use to deanonymize users. This proposal lays the groundwork by categorizing these issues, and prioritizes them according to their severity. Subsequent proposals will deal with specific solutions. I am posting just the intro section of this proposal here. The full proposal is at: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/344-pr… Filename: 344-protocol-info-leaks.txt Title: Prioritizing Protocol Information Leaks in Tor Author: Mike Perry Created: 2023-07-17 Purpose: Normative Status: Open 0. Introduction Tor's protocol has numerous forms of information leaks, ranging from highly severe covert channels, to behavioral issues that have been useful in performing other attacks, to traffic analysis concerns. Historically, we have had difficulty determining the severity of these information leaks when they are considered in isolation. At a high level, many information leaks look similar, and all seem to be forms of traffic analysis, which is regarded as a difficult attack to perform due to Tor's distributed trust properties. However, some information leaks are indeed more severe than others: some can be used to remove Tor's distributed trust properties by providing a covert channel and using it to ensure that only colluding and communicating relays are present in a path, thus deanonymizing users. Some do not provide this capability, but can be combined with other info leak vectors to quickly yield Guard Discovery, and some only become dangerous once Guard Discovery or other anonymity set reduction is already achieved. By prioritizing information leak vectors by their co-factors, impact, and resulting consequences, we can see that these attack vectors are not all equivalent. Each vector of information leak also has a common solution, and some categories even share the same solution as other categories. This framework is essential for understanding the context in which we will be addressing information leaks, so that decisions and fixes can be understood properly. This framework is also essential for recognizing when new protocol changes might introduce information leaks or not, for gauging the severity of such information leaks, and for knowing what to do about them. Hence, we are including it in tor-spec, as a living, normative document to be updated with experience, and as external research progresses. It is essential reading material for any developers working on new Tor implementations, be they Arti, Arti-relay, or a third party implementation. This document is likely also useful to developers of Tor-like anonymity systems, of which there are now several, such as I2P, MASQUE, and Oxen. They definitely share at least some, and possibly even many of these issues. Readers who are relatively new to anonymity literature may wish to first consult the Glossary in Section 3, especially if terms such as Covert Channel, Path Bias, Guard Discovery, and False Positive/False Negative are unfamiliar or hazy. There is also a catalog of historical real-world attacks that are known to have been performed against Tor in Section 2, to help illustrate how information leaks have been used adversarially, in practice. We are interested in hearing from journalists and legal organizations who learn about court proceedings involving Tor. We became aware of three instances of real-world attacks covered in Section 2 in this way. Parallel construction (hiding the true source of evidence by inventing an alternate story for the court -- also known as lying) is a possibility in the US and elsewhere, but (so far) we are not aware of any direct evidence of this occurring with respect to Tor cases. Still, keep your eyes peeled... 0.1. Table of Contents 1. Info Leak Vectors 1.1. Highly Severe Covert Channel Vectors 1.1.1. Cryptographic Tagging 1.1.2. End-to-end cell header manipulation 1.1.3. Dropped cells 1.2. Info Leaks that enable other attacks 1.2.1. Handshakes with unique traffic patterns 1.2.2. Adversary-Induced Circuit Creation 1.2.3. Relay Bandwidth Lying 1.2.4. Metrics Leakage 1.2.5. Protocol Oracles 1.3. Info Leaks of Research Concern 1.3.1. Netflow Activity 1.3.2. Active Traffic Manipulation Covert Channels 1.3.3. Passive Application-Layer Traffic Patterns 1.3.4. Protocol or Application Linkability 1.3.5. Latency Measurement 2. Attack Examples 2.1. CMU Tagging Attack 2.2. Guard Discovery Attacks with Netflow Deanonymization 2.3. Netflow Anonymity Set Reduction 2.4. Application Layer Confirmation 3. Glossary The remainder of this proposal can be read at: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/344-pr… -- Mike Perry

1 0

Calling Tor Volunteers and Developers! Help Shape the Future of Tor Relay Updates!
by Ravi Kumar 25 Jul '23

25 Jul '23

Dear Tor Volunteers and Developers, We are reaching out to you today to seek your invaluable expertise and insights in shaping the future of Tor relay updates. As part of an MSc Dissertation, a comprehensive study is underway to gain a deeper understanding of the significance of Tor relay updates from the unique perspective of developers like yourself. Your participation is pivotal to the success of this research, as we seek to explore your thoughts and opinions on a proposed automatic update mechanism for the relay. By lending your expertise, you will play a key role in advancing the health of the Tor network and enhancing the overall experience for millions of users around the globe. Rest assured that all your responses will be treated with the utmost care and confidentiality. To safeguard your data, the survey has been thoughtfully designed on an end-to-end encrypted platform, aligning with our commitment to ethical principles. We genuinely value your privacy and will handle your contributions with utmost respect and protection. We acknowledge the value of your time and effort, and we assure you that your input, which requires only 10 minutes, will wield a significant influence on the advancement of the Tor network. Don't miss out on this chance to contribute; the survey will remain open until August 5th. We invite you to join us today in shaping transformative research for Tor's bright future. Should you have any questions or require further information, please don't hesitate to contact us at S2450888(a)ed.ac.uk. We wholeheartedly welcome your feedback and queries, and your cooperation is genuinely appreciated. Together, we can make a meaningful difference and construct a stronger, more secure online world for everyone. Participate now and be an integral part of shaping the future of Tor relay updates through this link: https://cryptpad.fr/form/#/2/form/view/pb7wKm8zl0D62PsW93fz4wiW73i9nzDM-Jxc… [https://cryptpad.fr/customize/images/opengraph_preview/og-form.png]<https://cryptpad.fr/form/#/2/form/view/pb7wKm8zl0D62PsW93fz4wiW73i9nzDM-Jxc…> Encrypted Form<https://cryptpad.fr/form/#/2/form/view/pb7wKm8zl0D62PsW93fz4wiW73i9nzDM-Jxc…> CryptPad: end-to-end encrypted collaboration suite cryptpad.fr Thank you for your essential role in this important journey. Best regards, Ravi Kumar S2450888(a)ed.ac.uk The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th' ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.

1 0

Network Health team and analysis work
by Georg Koppen 06 Jul '23

06 Jul '23

Hello everyone! The Network Health team is best known for its work in the bad-relays area and being concerned with providing metrics + keeping an eye on the health of the Tor network. While that involves doing analyses to answer our own questions it was not clear so far what we should do with questions about the network or available data which got raised by other teams (i.e. you). Should we do those analyses as well or should we just provide the necessary data and each team then tries to answer their questions by themselves? This got raised a bunch of times in the past[1][2] and I am happy to announce that the Network Health team is stepping up and helping you with your analyses, if desired. The idea would be that we'd do the analysis work in those cases, alone or together, and accumulate/improve a set of scripts and tools over time at a single place, so that both we and other interested parties can do those analyses faster and better in the long(er) run. The tools should be open so that other folks can help improving and shaping them according to their needs. We have a dedicated analysis project[3] where we track all analysis related issues and which contains tools and documentation about how to use them for our work. If there is any analysis work you would like us to get done, please file a ticket in that project. If you did a similar analysis in the past by yourself we'd love to hear about it as it might speed up our work and we could build documentation out of it and add available code to the analysis project. Additionally, please assume we are no experts in your area of work, but don't hesitate to file tickets because of that. We'll ask if things are unclear. :) To get your analysis questions answered in a timely manner it would greatly help if they were attached to some sponsored work as that makes it usually easier to justify picking them up among all the other things on our plate. Additionally, emergencies (like new blocking events in country X) should be easily justifiable as well, in particular as we have a "surprise 'anomaly analysis' on the network as needed"-item on our roadmap throughout the year. I plan to make sure that we have sufficient spare cycles available for that work should it be needed. If your desired analysis does not fall into either of those categories don't despair, we'll try to find a way to get it done nonetheless. Thanks, Georg P.S.: If you are not part of any of our teams but want to do an analysis by yourself or just note an analysis idea somewhere, feel free to start by filing a ticket in the analysis project as well. Others might just jump on it and get it done because they might be curious about the answers themselves. :) [1] https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/iss… [2] https://gitlab.torproject.org/tpo/network-health/team/-/issues/250#note_286… [3] https://gitlab.torproject.org/tpo/network-health/analysis

1 0

[Update] Network Status APIs
by Mattia Righetti 06 Jul '23

06 Jul '23

Greetings Tor devs, During the last two weeks there has been an improvement in the Network Status APIs[0]. Network Status APIs is going to replace Onionoo web protocol as the Network Health Team moves most of the current bridges and relays data from files stored on disk to Postgres and VictoriaMetrics. We now have an initial working version of the `/summary` and `/bandwidth` endpoint. The first endpoint already has some working filters, while the latter does not yet. In the upcoming weeks we plan to stabilize and test these endpoints while we continue the development of others. The project initially started and was setup to look like a Onionoo copy to prevent most clients from breaking and for a smoother transition to the new protocol. We are now in the process of redefining some responses as the Onionoo implementation introduces some limitations. In particular, changes will affect responses that contain timeseries data stored on VictoriaMetrics as we thought it made more sense to just return a direct ref to VictoriaMetrics[1] for those requests, this way a client can decide to fetch referenced data or not based on its needs. Please do reach out to me, hiro or GeKo if you have any ideas or feedback you'd like to share with us. Cheers, Matt [0]: https://gitlab.torproject.org/tpo/network-health/metrics/networkstatusapi/ [1]: https://gitlab.torproject.org/tpo/network-health/metrics/networkstatusapi/-…

1 0

Network Status APIs
by Mattia Righetti 22 Jun '23

22 Jun '23

Greetings Tor devs, In an effort to improve current resource utilisation, the Network Health Status team is developing a new version of their pipeline [1]. Previously, much of the data was stored on files, this made many operations slow due to their I/O bound nature. The new pipeline will transfer much of the data related to Tor nodes and bridges from files stored on a single server's disk to two separate databases: Postgres and Victoria Metrics. With this new approach, there's the need to develop a new service that is going to replace the current onionoo web protocol [2]. The main objective of this project is to design a RESTful API service, using the actix_web framework, that is going to be integrated in the new pipeline v2.0 to support data retrieval of bridges and relays from the two databases and additionally provide new features such as historic data search. The project will be developed over the next few weeks as part of the GSoC sponsored program. Please do reach out to me, hiro or GeKo if you have any ideas or feedback you'd like to share with us. Cheers, Matt [1] https://gitlab.torproject.org/tpo/network-health/team/-/wikis/metrics/colle… [2] https://gitlab.torproject.org/tpo/network-health/metrics/networkstatusapi/

1 0

Two features that would help load-balanced bridges
by David Fifield 01 Jun '23

01 Jun '23

After the blocking of Tor in Russia in December 2022, the number of Snowflake users rapidly increased. Eventually the tor process became the limiting factor for performance, using all of one CPU core. In a thread on tor-relays, we worked out a design where we run multiple instances of tor on the same host, all with the same identity keys, in order to effectively use all the server's CPU resources. It's running on the live bridge now, and as a result the bridge's bandwidth use has roughly doubled. Design thread https://forum.torproject.net/t/tor-relays-how-to-reduce-tor-cpu-load-on-a-s… Installation instructions https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Gui… Two details came up that are awkward to deal with. We have workaround for them, but they could benefit from support from core tor. They are: 1. Provide a way to disable onion key rotation, or configure a custom onion key. 2. Provide a way to set a specific authentication cookie for ExtORPort SAFE_COOKIE authentication, or a new authentication type that doesn't require credentials that change whenever tor is restarted. I should mention that, apart from the load-balancing design we settled on, we have brainstormed some other options for scaling the Snowflake bridge or bridges. At this point, none of these ideas can immediately be put into practice, because there's no way to tell tor "connect to one of these bridges at random, but only one," or "connect to this bridge, but accept any of these fingerprints." https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… # Disable onion key rotation Multiple tor instances with the same identity keys will work fine for the first 5 weeks (onion-key-rotation-days + onion-key-grace-period-days), but after that time the instances will have independently rotated their onion keys, and clients will have connection failures unless the load balancer happens to connect them to the instance whose descriptor they have cached. This post investigates what the failure looks like: https://lists.torproject.org/pipermail/tor-relays/2022-January/020238.html Examples of what could work here are a torrc option to set onion-key-rotation-days to a large value, an option to disable onion key rotation, an option to set a certain named file as the onion key. What we are doing now is a bit of a nasty hack: we create a directory named secret_onion_key.old, so that a failed replace_file causes an early exit from rotate_onion_key. https://gitweb.torproject.org/tor.git/tree/src/feature/relay/router.c?h=tor… There are a few apparently benign side effects, like tor trying to rebuild its descriptor every hour, but it's effective at stopping onion key rotation. https://lists.torproject.org/pipermail/tor-relays/2022-January/020277.html # Stable ExtORPort authentication ExtORPort (extended ORPort) is a protocol that lets a pluggable transport attach transport and client IP metadata to a connection, for metrics purposes. In order to connect to the ExtORPort, the pluggable transport needs to authenticate using a scheme like ControlPort authentication. https://gitweb.torproject.org/torspec.git/tree/proposals/217-ext-orport-aut… tor generates a secret auth cookie and stores it in a file. When the pluggable transport process is managed by tor, tor tells the pluggable transport where to find the file by setting the TOR_PT_AUTH_COOKIE_FILE environment variable. In the load-balanced configuration, the pluggable transport server (snowflake-server) is not run and managed by tor. It is an independent daemon, so it doesn't have access to TOR_PT_AUTH_COOKIE_FILE (which anyway would be a different path for every tor instance). The bigger problem is that tor regenerates the auth cookie and rewrites the file on every restart. All the tor instances have different cookies, and snowflake-server does not know which it will get through the load balancer, so it doesn't know what cookie to use. Examples of what would work here are an option to use a certain file as the auth cookie, an option to leave the auth cookie file alone if it already exists, or a new ExtORPort authentication type that can use the same credentials across multiple instances. What we're doing now is using a shim program, extor-static-cookie, which presents an ExtORPort interface with a static auth cookie for snowflake-server to authenticate with, then re-authenticates to the ExtORPort of its respective instance of tor, using that instance's auth cookie. https://lists.torproject.org/pipermail/tor-relays/2022-January/020183.html

2 2

txtorcon v23.5.0
by meejah 19 May '23

19 May '23

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I'm happy to announce txtorcon 23.5.0 with the following changes: * twisted.web.client.Agent instances now use the same HTTPS policy by default as twisted.web.client.Agent. It is possible to override this policy with the tls_context_factory= argument, the equivalent to Agent's contextFactory= (Thanks to Itamar Turner-Trauring) * Added support + testing for Python 3.11. * No more ipaddress dependency You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/23.5.0 https://github.com/meejah/txtorcon/releases/tag/v23.5.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 93fd80a9dd505f698d0864fe93db8b6a9c1144b5feb91530820b70ed8982651c dist/txtorcon-23.5.0.tar.gz 987f0a91184f98cc3f0a7eccaa42f5054063744d6ac15e325cfa666403214208 dist/txtorcon-23.5.0-py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCgAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAmRm0DoRHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaae/+wgAw3gAm65npc7+yMdGFixNmCd+RUXorJq9 Hy76hK3BWdtNIA6TZF20QFYs3CX5Vepa0vCJOK1N40fYgxoZTb1/828Zp6Zq2+Gn piJGvQ0Z1S95ww7lwSV77o67Xf7PozhLR+k7DaOdY8ugvLb/0Rdp15BykF5DWIo8 PRgqB8uZ418ebmDLLrYtqYTdlcUMxFTji4CHXc4N55/2hVHiFiuFt59os6kJ3iG1 u90lmQH8vbDyVF7N6tpgEAdWeb7OdgDbtzhVBdBWHrPg+vDO+UL7WZU8ZjDAcdEr YzzmK3fIiCH7ngG2E/VIebiJfrjAA9G4eZXltIm7VcWh5css9MXY1Q== =TeQp -----END PGP SIGNATURE-----

1 0

Hacks to reduce Tor's initial download on slow Internet, sacrificing privacy?
by Holmes Wilson 08 May '23

08 May '23

Hi everyone, Is there a way right now to get Tor hidden service functionality (hosting a hidden service, connecting to hidden services) on a connection where the Internet is so slow and unreliable that the initial download of network information currently takes ~forever, provided one is willing to sacrifice metadata protection? Is there a way to download, say, 100x less network information on startup and still effectively host and connect to hidden services? Or is there a way to hardcode network information with the client, since that can be installed before going into the slow Internet zone, from a CDN that is less impacted, or from a source on the local network? (I read that this is how Tor worked in the past?) The context is the following: I have a p2p messaging app that uses Tor and hidden services (Quiet) in a way similar to Ricochet or Onionshare. I'm going to a conference where last year the Internet was so slow that Tor's initial download of network information took too long and kept timing out, rendering Quiet unusable. The Internet was, however, fairly reliable and usable for e.g. web browsing and messaging. I'd like to be able to use Quiet at this conference. It would be used purely as a demo for a few days, and we could warn everyone that our use of Tor did not offer its typical security properties. (Then in future years we might support p2p connectivity over local wifi, like Briar does!) My understanding is that the network information download step is to protect users against epistemic attacks. My intuition is that for situations where this doesn't matter there is some way to use Tor with a small subset of the network information and that the initial download could be skipped. Is this true? What's the best way to do it in the Tor client we ship? (I'm familiar with the Walking Onions paper, but looking for something that is ready now. There isn't already an implementation of Walking Onions, is there?) Thanks! Holmes

3 2

New Proposal - CAA Extensions for the Tor Rendezvous Specification
by Q Misell 08 May '23

08 May '23

Hi all, I've spent some time working on ACME for Tor hidden services (you may have seen discussion of this work on the onion-advisors mailing list). Full details of the project are available at https://e.as207960.net/w4bdyj/AX8Ffqsd Attached is my proposal for a change to the Tor Rendezvous Specification to support the inclusion of CAA records in hidden service descriptors. My fork of Tor implementing publishing these records is available at https://e.as207960.net/w4bdyj/XMN03dmD Thanks, 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>. 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. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively.

5 6

Suggestions for Arti Example Programs
by Saksham Mittal 08 May '23

08 May '23

Hello there! I was recently selected as a GSoC contributor to help improve Arti by providing example utilities to test drive the APIs. I've come up with a couple ideas in my GSoC proposal and I wanted to share them as well as ask the community if they had any ideas of what projects they may want to see included in examples to help developers use Arti APIs in the future. 1. A download manager in Rust which will download the Tor Browser Bundle through a bridge connection. 2. A simple DNS lookup tool like dig which uses Tor relay to resolve hostnames anonymously, reducing the need to trust a DNS server. (This will use DNS over TLS) 3. A small script to just print out the current connection info on the circuit that had been chosen (like in Tor Browser) and to test relay and bridge connectivity at the user’s end for diagnostic purposes. 4. A bridge reachability monitor using Arti. This tool would hold connections to many obfs4 bridges open and detect when one of them goes down. (More info about this can be found at https://gitlab.torproject.org/tpo/core/arti/-/issues/717) 5. A small proxy server and client which uses just the pluggable transport code to create obfuscated connection between the two (doesn't go through the Tor network, it is just intended to showcase how to setup connections through PTs) I'd be happy to know of any cool ideas you may have to build with Arti that I could work on this summer! Thanks! -Saksham

1 0

Re: [tor-dev] New Proposal - CAA Extensions for the Tor Rendezvous Specification
by Q Misell 27 Apr '23

27 Apr '23

Hi Raph, Whilst I agree that in an ideal world CAs would be irrelevant, we do not live in an ideal world. My proposal is one of many ways that a certificate could be issued to hidden services. Issuing standard TLS certificates to .onion domains allows HTTPS without modification to the browser. This allows non Tor Browsers user agents to access the Tor network via a proxy (SOCKS etc), doing otherwise would require all browsers to understand Tor. It also opens up new opportunities such as payment processing as current PCI DSS requirements do not allow non-standard TLS. Current hidden services with HTTPS such as the BBC already use standard TLS certificates, however the process for these is extremely involved with current CAs. My IETF draft aims to make this a much simpler process via the already well-proven ACME. Thanks, 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>. 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. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Thu, 27 Apr 2023 at 13:59, Raphaël Fabre <contact(a)fabco.tech> wrote: > Hey > > I've read your proposal, although I'm not sure to grap the totality of it. > I'm Raph the lead dev of this project -> https://e.as207960.net/w4bdyj/YG6dkkyr > > I have a question, since .onion is basically a non ICANN domain name > system, why do you care about using Certificate Authorities ? Could you > instead store the TLS certificates in the name system, as TXT / CERT > records (similar to DANE) ? > > Doing this would allow TOR service providers to not rely on certificate > authorities, control their TLS certificates directly (self signed) and *do > not need at all to renew it*. > > happy to chat further > Raph > > ------- Original Message ------- > Le jeudi 27 avril 2023 à 14:45, Q Misell via tor-dev < > tor-dev(a)lists.torproject.org> a écrit : > > Hi all, > > I've spent some time working on ACME for Tor hidden services (you may have > seen discussion of this work on the onion-advisors mailing list). Full > details of the project are available at https://e.as207960.net/w4bdyj/xqviywZW > <https://e.as207960.net/w4bdyj/yBzJUPTT>. > > Attached is my proposal for a change to the Tor Rendezvous Specification > to support the inclusion of CAA records in hidden service descriptors. > > My fork of Tor implementing publishing these records is available at > https://e.as207960.net/w4bdyj/ItcJLhNd <https://e.as207960.net/w4bdyj/LmAkW3uG>. > > Thanks, > 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://e.as207960.net/w4bdyj/pIFzAYXo>. ICO register №: ZA782876 > <https://e.as207960.net/w4bdyj/pZ2mD5UQ>. UK VAT №: GB378323867. EU VAT > №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: > 522-80-03080. Glauca Digital and the Glauca logo are registered trademarks > in the UK, under № UK00003718474 and № UK00003718468, respectively. > > >

1 0

goptlib moved to gitlab.torproject.org
by David Fifield 15 Apr '23

15 Apr '23

I have moved the goptlib repository from git.torproject.org to gitlab.torproject.org. If you want to use it at the new location, change this import: import "git.torproject.org/pluggable-transports/goptlib.git" to this: import "gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib" and then run `go get` and `go mod tidy`. Here is the issue about moving anti-censorship team projects from git.torproject.org to gitlab.torproject.org generally: https://bugs.torproject.org/tpo/anti-censorship/team/86#note_2823122 The old git.torproject.org URL should continue to work for the time being.

1 0

MSVC compile failure
by Gisle Vanem 21 Mar '23

21 Mar '23

Hello list. Anybody out there? Trying to compile Tor with 'cl' ver. 19.36.32323 from yesterdays 'git master', I got this error in 'src/feature/hs/hs_metrics_entry.c': hs/hs_metrics_entry.c(98,3): error C2099: initializer is not a constant { ^ hs/hs_metrics_entry.c(106,3): error C2099: initializer is not a constant { ^ ---------- This MSVC compiler is rather stupid; it fails to parse that 'static const size_t hs_metrics_circ_build_time_buckets_size' is truly 'const'. No problem with 'clang-cl'. But this patch works: --- a/feature/hs/hs_metrics_entry.c 2023-03-17 18:00:57 +++ b/feature/hs/hs_metrics_entry.c 2023-03-18 13:56:58 @@ -28,8 +28,7 @@ 60000 /* 60s */ }; -static const size_t hs_metrics_circ_build_time_buckets_size = - ARRAY_LENGTH(hs_metrics_circ_build_time_buckets); +#define hs_metrics_circ_build_time_buckets_size ARRAY_LENGTH(hs_metrics_circ_build_time_buckets) ----------------- Just letting you know here. -- --gv

2 3

Cross-user TLS traffic mixing in snowflake-server until 2023-03-13
by David Fifield 15 Mar '23

15 Mar '23

Between 2022-10-01 and 2023-03-13, there was a bug in the software deployed at Snowflake bridges that could cause parts of a user's stream to be overwritten by parts of other users' streams. Though the Snowflake team believes the privacy risks of the bug are minor, we are treating it as a security bug and therefore making this announcement. The fix is already deployed on the server, and no action is required by users. ## The cause The source of the bug was issue https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… and specifically commit https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…, which was intended as a performance optimization to reduce memory allocation during the large influx of Snowflake users in late September 2022. The analysis surrounding the performance improvement incorrectly concluded that certain memory buffers were not reused and therefore did not need to be copied. But in fact, the buffers were reused, with the effect that data meant for one user could be unpredictably overwritten by data for another user. ## The effect There is analysis at issue https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl…. If our understanding of the bug is correct, it did not reveal plaintext data or IP addresses to other users. The Snowflake bridge is a Tor bridge, not an exit relay, so even a catastrophic failure could not leak users' plaintext data or what destinations they were accessing. A Snowflake connection consists of a layered set of protocols, and the bug was in a layer that does not have access to IP addresses or any other persistent identifiers. * IP * TCP * HTTPS (WebSocket) * session/retransmission ← The bug was here * Tor TLS * user data At most, users and proxies would see fragments of other users' Tor TLS streams. We believe the degree of information disclosure is less than what an eavesdropper listening at the Snowflake bridge's HTTPS port would see, which we already believe to be safe. The practical effect, more than a loss of privacy, was excessive retransmissions at the session/retransmission layer, and corrupted TLS data resulting in a terminated connection. ## Remediation We reverted the erroneous commit and added a test to check for the erroneous buffer reuse. We deployed the update to both Snowflake bridges on 2023-03-13. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… ## Required action No action is required by users. The bug was in code that was only used by the Snowflake server, not proxies or clients. ## Thanks The problem was discovered and first investigated by Haz Æ 41 (https://gitlab.torproject.org/hazae41) and reported on HackerOne: https://hackerone.com/reports/1880610.

1 0

Is Arti expected to have better multi-CPU support than C-tor?
by David Fifield 08 Mar '23

08 Mar '23

Linus Nordberg and I are preparing a submission for FOCI about the special way we run tor on the Snowflake bridge. We run many tor processes with the same identity and onion keys, because otherwise tor being limited to one CPU would be the main bottleneck. I'm writing to fact-check a claim about Arti and how we hope the current complicated procedure will not be needed in the future: The first and most important bottleneck to overcome is the single-threaded nature of the Tor implementation.² A single Tor process is limited to one CPU core: once Tor hits 100% CPU, the performance of the bridge is capped, no matter the speed of the network connection or the number of CPU cores ²We expect that Arti, the in-progress reimplementation of Tor, will be natively multi-threaded, and remove this primary complication. Is this correct? Is a relay that uses a future version of Arti expected to be able to use all its CPU resources? Here is the a draft of the submission. If you have any comments, our submission deadline is 2023-03-15. https://www.bamsoftware.com/papers/pt-bridge-hiperf/pt-bridge-hiperf.202303… https://www.bamsoftware.com/papers/pt-bridge-hiperf/pt-bridge-hiperf.202303…

3 3

[CRITICAL] Deep Fingerprinting Traffic Correlation
by silentguard＠dnmx.org 28 Feb '23

28 Feb '23

Hi, I was the one who raised the issue of DeepCorr being able to perform traffic correlation with a high degree of accuracy but it seems like that WTF-PAD which is currently implemented in Tor does defend against the DeepCprr attack. I could be wrong but this seems to be my understanding. The feasability of this attack decreased when W-T (Walkie-Talkie) a half duplex anti-traffic correlation startegy is used. The accuracy with a W-T defense in place is 49% compared to a 90% accuracy with WTF-PAD. Thera There has been a new deep learning attack which is extremely effective against the current implementation of WTF-PAD in Tor. This new attacks is called Deep Fingerprining proposed here : https://arxiv.org/pdf/1801.02265.pdf. Thanks

1 0

[CRITICAL] DeepCorr Traffic Confirmation Attack
by silentguard＠dnmx.org 28 Feb '23

28 Feb '23

Hi, I was just reading a paper on traffic confirmation attacks over here https://arxiv.org/pdf/1808.07285v1.pdf. This attack runs with the help of deep learning algorithm called DeepCorr. This attack can be run in a Five Eyes country or an authoritarian regime like Russia where companies are compelled to cooperate with the government making this attack plausible. The ISP and the website operators are the two endpoints for this attack. This attack was able to achieve a success rate of over 96% which represents a serious threat to Tor users in these regions. The paper also includes some countermeasures on how to defeat this method of traffic confirmation. Thanks.

3 2

A way to connect quickly to a newly-online hidden service?
by Holmes Wilson 23 Feb '23

23 Feb '23

Hi everyone, In the p2p messaging app we're building, Quiet, users exchange some information out-of-band (an onion address) and use that to connect to each other over Tor, as they would for direct messages in Ricochet Refresh or Cwtch. One UX failure we see now is that newly-online hidden services are not available when users first try to connect, so connecting after users have just come online takes unreasonably long (15 minutes or more) and Quiet seems like it's broken. Any thoughts on how to speed up connecting to a newly-online hidden service? One idea we had is to include enough information from the HSDir entry in what peers exchange out-of-band, so that they wouldn't need to rely on finding the HSDir entry. (And if this information became out of date, we could simply encourage users to share information out of band again.) Is there an easy way for us to get this information from Tor on the receiver side and pass it to Tor when connecting? Another idea was to run some service of our own as a fallback, that we knew would always have the latest HSDir entries posted by our users. Is there some straightforward way to hardcode our own HSDir so that Tor would always check it alongside others? If I'm reading the situation wrong or there's some other possibility I'm not thinking of, please let me know! We've definitely observed long delays in onion addresses becoming available, on top of general connection delays, and I'm trying to find a way to improve this situation. Thanks! Holmes

2 1

The future of Tor client software?
by Steven Engler 21 Feb '23

21 Feb '23

Hi tor-dev, In the past, there were generally two options for supporting Tor in an application. 1. Require the user to install the tor daemon (ex: apt install tor, Tor Expert Bundle, etc) and configure the application to use its SOCKS proxy. 2. Bundle the tor binary with the application (ex: Tor Browser) and have the application use the app-specific tor process as the SOCKS proxy. I'm not clear on how this changes in an Arti world. Arti currently has a Rust Tor client library for applications, and a CLI application to run a SOCKS proxy. Is there any plan to offer an Arti daemon (ex: a systemd service) for clients like with the current tor package? In a future where Arti replaces the Tor client and relay code, or when Arti is recommended for all client-related use cases, will there continue to be a Tor daemon with client support? I see various possibilities for developers who wish to use Tor in their applications: 1. Require users to install/run a Tor system service (whether it's tor or arti). - pros: - shared resource usage (mainly circuits) between applications - familiar to experienced Tor users - cons: - requires an additional installation step for users - easy to break by users (for example changing their SOCKS port) - can't modify the Tor client's configuration (ex: can't enable DNSPort, change SocksPort flags, etc) 2. Bundle tor/arti binaries with the application. - pros: - simple for users (no extra configuration needed) - more control over the Tor client's configuration - cons: - can be brittle (ex: an application is already using port 9150) - resources/circuits are not shared between applications - more work for the application developer (needs to build and bundle the tor binary) - (presumably) slower start-up times since there is no pre-existing pool of pending circuits, and descriptors may be out-of-date 3. Use the arti-client library in the application. - pros: - simple for users (no extra configuration needed) - more control over the Tor client's configuration - easy to use for rust application developers - cons: - likely difficult to use in non-rust applications (writing an ffi for the async arti-client API doesn't sound fun) - resources/circuits are not shared between applications - (presumably) slower start-up times since there is no pre-existing pool of pending circuits, and descriptors may be out-of-date 4. Require users to install/run a Tor transparent proxy or TUN adapter. - pros: - should probably "just work" (ex: no SOCKS port that can change or need to be configured) - cons: - requires an additional installation step for users - can't modify the Tor client's configuration - users likely don't want to proxy all their traffic through Tor - slowdowns due to latency from DNS lookups (RELAY_RESOLVE instead of sending the hostname in the RELAY_BEGIN) - no stream isolation support (maybe?) Are there any guidelines for what method should be used under different circumstances? For example using the arti-client library in an email client seems reasonable since a longer startup time while it builds circuits isn't a big deal. But it might be a bad idea to use the arti-client library in cURL, which would need to build circuits each time curl is invoked in a shell script. - Steve

2 3

Simple tool for mobile remote desktops
by Micah Elizabeth Scott 24 Jan '23

24 Jan '23

Hello, This is an almost trivial utility but I hadn't seen anything quite like it so maybe other folks will find it useful: https://github.com/scanlime/onion-desktop "This is just a toy for now. I wanted to get a feel for the interactive performance of onion services, and it's perhaps sometimes useful if you'd like to share a disposable slice of your computer with a phone when they're both behind NAT. This is a very simple Docker container that runs an xfce4 desktop, novnc, and tor. It will randomly generate a new onion service URL and a VNC password, and show you a tmux with session logs on the left and a big QR code you can scan on the right." Nothing too fancy, just some shell script and Docker and a lot of Debian. The readme has a couple screenshots if you're curious. Cheers, --micah beth

2 1

Proposal 342: Decouple hs_interval and SRV lifetime
by Nick Mathewson 24 Jan '23

24 Jan '23

``` Filename: 342-decouple-hs-interval.md Title: Decoupling hs_interval and SRV lifetime Author: Nick Mathewson Created: 9 January 2023 Status: Draft ``` # Motivation and introduction Tor uses shared random values (SRVs) in the consensus to determine positions of relays within a hash ring. Which shared random value is to be used for a given time period depends upon the time at which that shared random value became valid. But right now, the consensus voting period is closely tied to the shared random value voting cycle: and clients need to understand both of these in order to determine when a shared random value became current. This creates tight coupling between: * The voting schedule * The SRV liveness schedule * The hsdir_interval parameter that determines the length of the an HSDIR index To decouple these values, this proposal describes a forward compatible change to how Tor reports SRVs in consensuses, and how Tor decides which hash ring to use when. ## Reporting SRV timestamps In consensus documents, parties should begin to accept `shared-rand-*-value` lines with an additional argument, in the format of an IsoTimeNospace timestamp (like "1985-10-26T00:00:00"). When present, this timestamp indicates the time at which the given shared random value first became the "current" SRV. Additionally, we define a new consensus method that adds these timestamps to the consensus. We specify that, in the absence of such a timestamp, parties are to assume that the `shared-rand-current-value` SRV became "current" at the first 00:00 UTC on the UTC day of the consensus's valid-after timestamp, and that the `shard-rand-previous-value` SRV became "current" at 00:00 UTC on the previous UTC day. ## Generalizing HSDir index scheduling. Under the current HSDir design, there is one SRV for each time period, and one time period for which each SRV is in use. Decoupling `hsdir_interval` from 24 hours will require that we change this notion slightly. We therefore propose this set of generalized directory behavior rules, which should be equivalent to the current rules under current parameters. The calculation of time periods remains the same (see `rend-spec-v3.txt` section `[TIME PERIODS]`). A single SRV is associated with each time period: specifically, the SRV that was "current" at the start of the time period. There is a separate hash ring associated with each time period and its SRV. Whenever fetching an onion service descriptor, the client uses the hash ring for the time period that contains the start of the liveness interval of the current consensus. Call this the "Consensus" time period. Whenever uploading an onion service descriptor, the service uses _two or three_ hash rings: * The "consensus" time period (see above). * The immediately preceding time period, if the SRV to calculate that hash ring is available in the consensus. * The immediately following time period, if the SRV to calculate that hash ring is available in the consensus. (Under the current parameters, where `hsdir_interval = SRV_interval`, there will never be more than two possible time periods for which the service can qualify.) ## Migration We declare that, for at least the lifetime of the C tor client, we will not make any changes to the voting interval, the SRV interval, or the `hsdir_interval`. As such, we do not need to prioritize implementing these changes in the C client: we can make them in Arti only. ## Issues left unsolved There are likely other lingering issues that would come up if we try to change the voting interval. This proposal does not attempt to solve them. This proposal does not attempt to add flexibility to the SRV voting algorithm itself. Changing `hsdir_interval` would create a flag day where everybody using old and new values of `hsdir_interval` would get different hash rings. We do not try to solve that here. ## Acknowledgments Thanks to David Goulet for explaining all of this stuff to me!

4 7

Tor Bridges and Snowflakes detection attack
by tor＠nullvoid.me 09 Jan '23

09 Jan '23

Hi, https://github.com/scriptzteam/Tor-Bridges-Collector Seems an attacker has found a way to enumerate ~300000 snowflakes and many bridges. I couldn't find any discussion about this in the archive. Thanks,

4 4

Typo in relay metrics (circs_creared)
by Andreas Bollhalder 09 Jan '23

09 Jan '23

Hi I think, there's a typo in the file "src/feature/relay/relay_metrics.c". Shouldn't the word "circs_creared" in the line metrics_format_label("action", "circs_creared")); be read as "circs_cleared"? Andreas PS: Sorry, at the moment I've no clue what would be the correct way to send patches...

2 2