tor-dev

tor-dev@lists.torproject.org

3580 discussions

txtorcon 24.8.0
by meejah 20 Aug '24

20 Aug '24

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I'm gruntled to announce txtorcon 24.8.0 with the following changes: * Fix (test) issues with Twisted 24.7.0 (https://github.com/meejah/txtorcon/pull/400) * Remove usage of "six" (https://github.com/meejah/txtorcon/issues/395) from https://github.com/a-detiste txtorcon is an implementation of the "control-spec" for Tor using the "Twisted" networking library. This is the library to use if you want to write event-based software (including asyncio; interop is possible) in Python that uses the Tor network as a client or a service (or to integrate Tor support into existing Twisted-using applications). You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/24.8.0 https://github.com/meejah/txtorcon/releases/tag/v24.8.0 Releases are also available from the hidden service: http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check f790ab645a43a801ec68402467c15b2c816b6d16d93b36b89eed9ee9d17cc51f dist/txtorcon-24.8.0.tar.gz d3d0871a19c2ecaaae9e2c13b302a78b169048f5a3c2051069a2ea6ae44232c7 dist/txtorcon-24.8.0-py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCgAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAmbE8TQRHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaaeMTggAzkQ81pbZEN149nyR08zFzj2/oXWj5RzH huB4UDYmPTkzT7YvyI1e7CbcavLU7VEpcJCtEvFHsVx4PNG9cwc/Bd0/M8w0YVKM bNsijPX+d4SGZSL3rVwzKoMDPo6mm1fUiDgWFVZqqZ5PUagFKF7/iTvKShq4AVBe kwDJa2eiku3UDXcNRtbNtp+xxzrUIK5TcaUImeEXHIiQxsQJNbaL492FQXxYY2sM CFnGKH7QYkyQ8iFkVvqO7yaVI7oB1rFvD9FLrZXPHN+W2MIBG7ncfROs6LuBQQRC SuC+audP7Rbuf4uZp5RpdxQTkV2+k8L5mfAdu+k/WiihnsVoX1owdA== =wCIY -----END PGP SIGNATURE-----

1 0

Tor community papers at Usenix Security
by Roger Dingledine 26 Jul '24

26 Jul '24

Here are seven papers that I think our community will find interesting from the upcoming Usenix Security conference, August 14-16. Many of them are written by our very own university relay operators, too. :) --Roger "Snowflake, a censorship circumvention system using temporary WebRTC proxies" Cecylia Bocovich, Tor Project; Arlo Breault, Wikimedia Foundation; David Fifield and Serene, unaffiliated; Xiaokang Wang, Tor Project https://www.usenix.org/conference/usenixsecurity24/presentation/bocovich "Stop, Don't Click Here Anymore: Boosting Website Fingerprinting By Considering Sets of Subpages" Asya Mitseva and Andriy Panchenko, Brandenburg University of Technology (BTU Cottbus, Germany) https://www.usenix.org/conference/usenixsecurity24/presentation/mitseva "Does Online Anonymous Market Vendor Reputation Matter?" Alejandro Cuevas and Nicolas Christin, Carnegie Mellon University https://www.usenix.org/conference/usenixsecurity24/presentation/cuevas "Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes" Diwen Xue, University of Michigan; Michalis Kallitsis, Merit Network, Inc.; Amir Houmansadr, UMass Amherst; Roya Ensafi, University of Michigan https://www.usenix.org/conference/usenixsecurity24/presentation/xue-fingerp… ""I just hated it and I want my money back": Data-driven Understanding of Mobile VPN Service Switching Preferences in The Wild" Rohit Raj, Mridul Newar, and Mainack Mondal, Indian Institute of Technology, Kharagpur https://www.usenix.org/conference/usenixsecurity24/presentation/raj "Security and Privacy Software Creators' Perspectives on Unintended Consequences" Harshini Sri Ramulu, Paderborn University & The George Washington University; Helen Schmitt, Paderborn University; Dominik Wermke, North Carolina State University; Yasemin Acar, Paderborn University & The George Washington University https://www.usenix.org/conference/usenixsecurity24/presentation/ramulu "GFWeb: Measuring the Great Firewall's Web Censorship at Scale" Nguyen Phong Hoang, University of British Columbia and University of Chicago; Jakub Dalek and Masashi Crete-Nishihata, Citizen Lab - University of Toronto; Nicolas Christin, Carnegie Mellon University; Vinod Yegneswaran, SRI International; Michalis Polychronakis, Stony Brook University; Nick Feamster, University of Chicago https://www.usenix.org/conference/usenixsecurity24/presentation/hoang

1 0

Fwd: Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes
by Sam 16 Jul '24

16 Jul '24

System wrote via Tor Project <noreply(a)forum.torproject.org>:Feedback: Please submit the proposal also to tor-dev: tor-dev Info PageIntroducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes https://www.reddit.com/r/TOR/comments/1e4te8m/introducing_discussing_reflec… ==============================================================Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes *Tor-Messaging: Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay |* Hello, I think this belongs to this core, general, relay topic-forum, as it is also a development & community issue, request and efford, I post it here into the reddit forum for your core discussion: The idea is to add next to Bridges, Relays and Exit-Nodes also "Entry-Nodes" as "Reflec-Tor"(s) to the point of Exit-Nodes. Hence: Exit-Nodes are developed futher to be also an Entry-Node. Some may remember when gnutella got hybrid with edonkey and then also with torrent, Mike Stokes from Shareaza did that. The idea today, 20 years later, is to add some Echo-capabilities to Tor in regard of the servers for Exit and Entry. *Vision: Every (updated) Exit-Node is an Echo-Server - For a better Tor-Messaging.* What does that mean? An Echo-Server is a server for chat-messaging to send an incomming message packet again out to all connected clients at the moment. Ping-in and Ping-Out to all. That simple, that's why it is called the Echo. Like a shout in front of a forrest, all connected users can hear and get the (encrypted) shout or message or packet back from the tree wall. There are 3 software applications for Echo-Servers: - https://github.com/textbrowser/spot-on (Desktop, sercer in the Listener Tab) - https://github.com/textbrowser/smokestack (java for Android) - https://github.com/textbrowser/spot-on-lite (headless deamon for Linux) Now, the Listener function with ping in and ping out should be implemented within a Tor-Exit-Node. When it comes to Tor-Messaging, there are some pathes possible: A) Tor-Chat-Client-Alice - Tor - Internet - Echo-Server - Internet - Tor - Tor-Chat-Client-Bob (Tor-proxied Chat-Server, which only accepts encrypted packets) B) Tor-Chat-Client-Alice - Echo - Tor - Tor - Echo - Tor-Chat-Client-Bob (Echo Tor-tunneled) C) Tor-Chat-Client-Alice - Echo-Server - Tor-Chat-Client-Bob (direct connection to Echo-Server with only encypted packets) The request here is to build and develop option A. That is just right now also possible, by an Exit-Node of Tor running the Echo-Server-Software on the same machine in parallel. Just the port is different. This is an idea for some might be new, but thinking Tor Messaging a bit, it comes quickly to this ideas and better soluttion. The way to connect D) Tor-Chat-Client-Alice - Hidden Onion Server v3 - Tor - Tor - Hidden Onion Server v3 - Tor-Chat-Client-Bob is the current given way for clientes like RicoChet Refresh, Quiet or Cwtch. Similar to Briar, even developers of such clients above tell the loss of messages and low reliability of the hidden to hidden path. Some of you might know, that there were use cases with missing messages in a range of 35-45 %. Don't quote me on that, but as core developers and community members you might be in contact with those who experience this. Furthermore the Messaging clients are not advanced in functionality, nor advanced in strong encryption. It would be third a long development way to got that route. It is cost effective and needs cappable developers. Some project have stamped on and made a workable client, but does that unite all our power in the sense of Tor-Messaging? Messaging needs a Vision and Statement from the Tor-Core-Developer team with a discussion in the community in that regard with honor to the individual projects and also with support for their chosen path (Model D). At the same time we have to state that it is as it is, a HTTP-Server in the middle like in Model A is faster than Model D. In the graph-path the Echo-Server in the middle handles only encrypted traffic, so it is just like another Relay. We can call it "Reflec-Tor". The only sense it to multiply incomming encrypted packets from one node to all connected nodes. With that Idea, the Messenger Spot-On could be used as a Tor-Messenger. This Messenger has stong encryption and is full of feature for messaging and also cryptography. it is like adding Firefox to Tor-Browsing, when Spot-On is added to Tor-Messaging. Something to read at the community forum: https://www.reddit.com/r/Spot_On_Encryption/ Also there is a Mobile Client for Android, which also connects to Reflec-Tors, find "Smoke" Messenger at F-Droid.org. Please, get this right, it is not about a technical view on slow and failing chat-packets to hidden servers, and it is not about those start-up clients using this inside technology, some do a good project. It is about the idea, that an Reflec-Tor mirroring and pinging back packets on the Exit-Node this hop within the path of tor is not outside, it is always fully encryted for the messaging packets and should be seen as one Tor-Path, especially if the Listener-Ping-Back function (the Echo capabilities) is build in the Exit-Node-Tor Software. Spot-On is already a Tor-Messenger - as it uses also HTTPs and it sends only encrypted packets. *A test is easy to make:* (1) Start the Tor-Browser, which has always the Port 9051 to Tor, Tor is running. Next to Surfing with Tor-Browser Firefox the Chat with Tor-Messenger Spot-On can start. (2) Start Spot-On on a webserver and create in the Listeners Tab a Listener on Port 4710. (3) Start two Spot-On Instances Alice and Bob on two Laptops, in the Neighbors Tab you connect the Webserver via Tor: Add the IP and Port 4710 to the neighbor and choose Proxy: 127.0.0.1 Port 4710. You get the the Path: Tor-Chat-Client-Alice - Tor - Internet - Echo-Server - Internet - Tor - Tor-Chat-Client-Bob The idea is now to integrate this a bit more: Tor-Chat-Client-Spot-On-Alice - Tor - [Tor-Exit-Node also Reflec-Tor (Echo-Server)] - Tor - Tor-Chat-Client-Spot-On-Bob You see, the way stays all within the Tor-Family. For sure, in case Alice does not want to use Tor, she also can message to Bob, who is behind Tor. Tor-Chat-Client-Spot-On-Alice --> [Tor-Exit-Node as Entry-Node also Reflec-Tor (Echo-Server)] - Tor - Tor-Chat-Client-Spot-On-Bob The IP of an Entry-Node is shown in the Tor-Browser and can get a port added. Then two user can simply cata over that node. We need in times of surveillance, data retention, chat control and for sake of the needs of whistleblowser and people who want to chat privat and anonymously more decentral and open source chat server. *The mission is: Every Tor-Exit Node is an Entry-Node for Chat.* It should be not a lot of code to be added to the ports of an Exit-Node and displaying the Port of the Exit-Node in the Tor-Browser path icon. This makes sense in several effects to be discussed and developed further: - Taking the next Development Step for Tor-Messaging: BTW, A Forum about Tor-Messaging could be made as a category here in the forum please. - directly support Tor-based Messaging for the Spot-On Messaging client To be developed and discussed is, if this infra-structure could help to - support bootstrapping of Tor - support Censorship circumvention of Tor Reflec-Tors as SnowFlakes over the Messenger with EPKS - Accept, that some routing to an HTTPS internet server at the Tor-Node is faster than to an hidden onion server at the Tor Node. Well, to add some "ping-in-and-out" for an packet is what every netcat and socat under linux can do. It is a small development step to make each Tor-Exit node a free chat server for messaging, which is a big step for mankind to have a network of free messaging chat servers. Lets also see, how users and community will test and develop this messaging. So it is not only a discussion for developers, it is also a step forward the needs of the communities *for a free internet:* - *for chat and their discussions.* A few code lines to exit nodes make them a Reflec-Tor and messaging over Tor can start really decentral and open source and free. *What do you think?* does this privacy-concept bring more privacy and reliability in packet delivery to messaging with Tor? Regards

1 0

Some Gosling Updates!
by Richard Pospesel 06 Jul '24

06 Jul '24

Hi Everyone! It's been a minute since the last time I posted to this list about Gosling (December, 2021 what the actual heck: https://lists.torproject.org/pipermail/tor-dev/2021-December/014684.html ). Well, since then I have been quite busy leading the applications team and shipping browsers by day, and developing Ricochet-Refresh and Gosling by night! To summarise, gosling is a Rust crate (and cgosling is a C-FFI library) which generalises and encapsulates all the hard parts of building peer-to-peer applications using tor, where a peer's long-term identity is an onion-service id. My vision and hope is that this allows for the creation new peer-to-peer applications with all of the various properties and guarantees of tor baked in, and that developers won't need to go spend some years becoming tor experts to do it correctly and safely. The next version of Ricochet-Refresh will be using Gosling as its foundation, and so of course heavily informed Gosling's features and development direction. The specific properties/features offered by Gosling: - long-term peer identity: an onion-service id - anonymous: it's onion-services and tor - secure: end-to-end encrypted from tor-client to tor-client because tor - nat-punching: more tor - censorship-circumvention: tor + pluggable-transports and bridges Ok and the novel/harder stuff: - authentication: cryptographically prove connecting clients control the private key of their claimed onion-service identity and their provided client-auth keys - customisable/application-specific handshakes: on top of the baseline cryptographic authentication, the 'add me as a peer' handshake also allows for an additional challenge+response requirement; imagine for instance a one-time code verification, password verification, socialist millionaire scheme, proof-of-work or stake, etc - metadata-resistant: the only metadata available to untrusted clients is your primary identity's onion-service's online/offline status; this onion-service is not required to be online to connect with trusted clients (unlike with other Ricochet-derived IM clients) If any of this sounds exciting or useful to you, I'd love to invite you over to the project Github to take a look: - https://github.com/blueprint-freespeech/gosling I'm hoping for Gosling to hit version 1.0.0 and lock-down/converge on a plausible stable API before the end of this year. The current API surface is very informed by my experience with what would be useful for Ricochet-Refresh, but I'm sure there are blind-spots here or improvements that could be made for other potential use-cases. The goal from day one has been to make this code usable outside the Rust ecosystem. To that end, I've tried to make the C-FFI API design consistent, familiar and safe as possible, since it eventually will be used from Ricochet-Refresh's C++ codebase. --- The vast majority of the protocol work and initial implementation was completed around the beginning of 2023. So what have I been up to for the past couple years? Basically, all of the 'boring' (quite exciting actually) software engineering work to get Gosling both usable and trustworthy. To be specific, I've been working on the following areas: - code-cleanup: refactored Gosling into separate crates which may be individually useful: - honk-rpc: the bson-based, json-rpc inspired RPC protocol - tor-interface: probably should have a better name, but this encapsulates the tor-daemon configuration and lifecycle, control-port communications, and connectivity - gosling: the Rust protocol implementation - cgosling: gosling wrapped in a safe+friendly C-FFI - improved CMake project layout; cgosling should be relatively usable/integratable into existing CMake projects - build+test automation: build and run tests on github CI/CD Linux, macOS, and Windows runners, publish code-coverage, generated Rust documentation, doxygen C/C++ documentation - fuzzing: fuzz the Rust crates including the C-FFI - identified and fixed a lot of bugs in the entire stack this year :D - language bindings: build a cbindgen -> c-header -> json idl pipeline for the cgosling crate; json idl used to automatically generate: - C/C++ headers, static+shared libraries - python bindings to shared library - Java/JNI shared library and jar - packaging/deployment - published Rust crates to crates.io - deb-source package generation for debian-based Linux - homebrew flask formula generation for macOS - MSYS2 pkgbuild generation for Windows - some minor new features: - connect API to connect to non-gosling onion-services and clearnet targets using tor - use an already-running tor rather than running/configuring own tor process - configure bundled tor with all the familiar stuff: proxy, firewall, pluggable transports, and bridges - initial protoyping for in-proc arti-client backend (currently on version 0.18 so a bit behind) The remaining planned work in this area before hopefully shifting my focus back on Ricochet-Refresh are a documentation pass on all my Rust crates, cleaning up/documenting the example projects, and completing a security audit. The Java and Python bindings could also use some love and automation. -- Anyway, I think that's enough technical non-sense for your inbox. If any of this sounds interesting, come check things out the project website ( https://gosling.technology/ ) which links to all the relevant stuff. best, -richard

1 0

Proposal 350: A phased plan to remove TAP onion keys
by Nick Mathewson 31 May '24

31 May '24

``` Filename: 350-remove-tap.md Title: A phased plan to remove TAP onion keys Author: Nick Mathewson Created: 31 May 2024 Status: Open ``` ## Introduction Back in [proposal 216], we introduced the `ntor` circuit extension handshake. It replaced the older `TAP` handshake, which was badly designed, and dependent on insecure key lengths (RSA1024, DH1024). With the [final shutdown of v2 onion services][hsv2-deprecation], there are no longer any supported users of TAP anywhere in the Tor protocols. Anecdotally, a relay operator reports that fewer than one handshake in 300,000 is currently TAP. (Such handshakes are presumably coming from long-obsolete clients.) Nonetheless, we continue to bear burdens from TAP support. For example: - TAP keys compose a significant (but useless!) portion of directory traffic. - The TAP handshake requires cryptographic primitives used nowhere else in the Tor protocols. Now that we are implementing [relays in Arti], the time is ripe to remove TAP. (The only alternative is to add a useless TAP implementation in Arti, which would be a waste of time.) This document outlines a plan to completely remove the TAP handshake, and its associated keys, from the Tor protocols. This is, in some respects, a modernized version of [proposal 245]. ## Migration plan Here is the plan in summary; we'll discuss each phase below. - Phase 1: Remove TAP dependencies - Item 1: Stop accepting TAP circuit requests. - Item 2: Make TAP keys optional in directory documents. - Item 3: Publish dummy TAP keys. - Phase 2: After everybody has updated - Item 1: Allow TAP-free routerdescs at the authorities - Item 2: Generate TAP-free microdescriptors - Phase 3: Stop publishing dummy TAP keys. Phase 1 can begin immediately. Phase 2 can begin once all supported clients and relays have upgraded to run versions with the changes made in Phase 1. Phase 3 can begin once all authorities have made the changes described in phase 2. ### Phase 1, Item 1: Stop accepting TAP circuit requests. (All items in phase 1 can happen in parallel.) Immediately, Tor relays should stop accepting TAP requests. This includes all CREATE cells (not CREATE2), and any CREATE2 cell whose type is TAP (0x0000). When receiving such a request, relays should respond with DESTROY. Relays MAY just drop the request entirely, however, if they find that they are getting too many requests. Such relays must stop reporting `Relay=1` among their supported protocol versions. (This protocol version is not currently required or recommended.) > If this proposal is accepted, > we should clarify the protocol version specification > to say that `Relay=1` specifically denotes TAP. ### Phase 1, Item 2: Make TAP keys optional in directory documents. (All items in phase 1 can happen in parallel.) In C tor and Arti, we should make the `onion-key` entry and the `onion-key-crosscert` entry optional. (If either is present, the other still must be present.) When we do this, we should also modify the authority code to reject any descriptors that do not have these fields. (This will be needed so that existing Tor instances do not break.) In the microdescriptor documents format, we should make the _object_ of the `onion-key` element optional. (We do not want to make the element itself optional, since it is used to delimit microdescriptors.) We use new protocol version flags (Desc=X, Routerdesc=Y) to note the ability to parse these documents. ### Phase 1, Item 3: Publish dummy TAP keys (All items in phase 1 can happen in parallel.) Even after step 2 is done, many clients and relays on the network will still require TAP keys to be present in directory documents. Therefore, we can't remove those keys right away. Relays, therefore, must put _some_ kind of RSA key into their `onion-key` field. I'll present three designs on what relays should do. We should pick one. > #### Option 1 (conservative) > > Maybe, we should say that a relay > should generate a TAP key, generate an onion-key-crosscert, > and then discard the private component of the key. > #### Option 2 (low-effort) > > In C tor, we can have relays simply proceed as they do now, > maintaining TAP private keys and generating crosscerts. > > This has little real risk beyond what is described in Option 1. > #### Option 3 (nutty) > > We _could_ generate a global, shared RSA1024 private key, > to be used only for generating onion-key-crosscerts > and placing into the onion-key field of a descriptor. > > We would say that relays publishing this key MUST NOT > actually handle any TAP requests. > > The advantage of this approach over Option 1 > would be that we'd see gains in our directory traffic > immediately, since all identical onion keys would be > highly compressible. > > The downside here is that any client TAP requests > sent to such a relay would be decryptable by anybody, > which would expose long-obsolete clients to MITM attacks > by hostile guards. We would control the presence of these dummy TAP keys using a consensus parameter: `publish-dummy-tap-key` — If set to 1, relays should include a dummy TAP key in their routerdescs. If set to 0, relays should omit the TAP key and corresponding crosscert. (Min: 0, Max, 1, Default: 0.) We would want to ensure that all authorities voted for this parameter as "1" before enabling support for it at the relay level. ### Phase 2, Item 1: Allow TAP-free routerdescs at the authorities Once all clients and relays have updated to a version where the `onion-key` router descriptor element is optional (see phase 1, item 2), we can remove the authority code that requires all descriptors to have TAP keys. ### Phase 2, Item 2: Generate TAP-free microdescriptors Once all clients and descriptors have updated to a version where the `onion-key` body is optional in microdescriptors (see phase 1, item 2), we can add a new consensus method in which authorities omit the body when generating microdescriptors. ### Phase 3: Stop publishing dummy TAP keys. Once all authorities have stopped requiring the `onion-key` element in router descriptors (see phase 2, item 1), we can disable the `publish-dummy-tap-key` consensus parameter, so that relays will no longer include TAP keys in their router descriptors. [proposal 216]: ./216-ntor-handshake.txt [proposal 245]: ./245-tap-out.txt [hsv2-deprecation]: https://support.torproject.org/onionservices/v2-deprecation/ [relays in Arti]: https://gitlab.torproject.org/tpo/team/-/wikis/Sponsor%20141

2 1

Key Blinding Secrets
by Bellebaum, Thomas 04 May '24

04 May '24

Hello everyone, I am a researcher currently looking into different schemes for what you call Keyblinding in the rendevouz spec. https://spec.torproject.org/rend-spec/keyblinding-scheme.html I noticed that your description there mentiones a secret `s` to be hashed into the blinding factor, and have a few questions about it: 1. Is this secret currently being used / intended to be used? If so, how? 2. What kinds of security (formally or informally) would you expect from using a secret in the derivation process? For example, do you just require that someone without `s` cannot look up the service, or is this also meant as a way of ensuring that HSDir nodes cannot find correlations between services and descriptors (amounting to some sort of additional censorship resistance)? The reason I am asking is because my research has identified some potentially post quantum secure schemes which for unknown identity keys results in uncorrelatable blinded keys, but where for known public keys you can efficiently determine whether a blinded key is its derivative, even if you do not know the blinding factor. I am wondering for which kinds of applications (with TOR being a major one) this would be relevant. If you have any insights, please let me know. Also I am new to the TOR-Dev world, so feel free to send me to a different mailing list, should I have chosen the wrone one for this topic :) Thanks in advance, Thomas -- ``` M.Sc. Thomas Bellebaum Applied Privacy Technologies Fraunhofer Institute for Applied and Integrated Security AISEC Lichtenbergstraße 11, 85748 Garching near Munich (Germany) Tel. +49 89 32299 86 1039 thomas.bellebaum(a)aisec.fraunhofer.de https://www.aisec.fraunhofer.de ```

2 1

Proposal for Tor (Relay) Watchdog (Telegram) Bot
by Alessandro Greco 29 Apr '24

29 Apr '24

Dear Tor Project Developers, I hope this email finds you well. I am writing to share with you a project [1] I have been working on called Tor Watchdog Bot [2], and I believe it may be of interest to you. Tor Watchdog Bot is a Telegram bot designed to monitor the status of Tor relays and notify users when relays go offline. The intent behind creating this bot was to develop a user-friendly tool that allows anyone to easily keep track of their Tor nodes. I am fully aware that the bot is not currently ready for public release as it requires several bug fixes and improvements. Before proceeding with further development, I wanted to ensure that this project aligns with your interests and goals. In order to prioritize user privacy and security, I did not activate the backend feature with the actual functionality; instead, I activated a demo that always provides the same results but allows users to understand the type of response they would receive if it were active. In the README.md file, you will find detailed instructions on how to set up and test the bot. If you find this project interesting and believe it could be beneficial to the Tor community, I would be delighted to see Tor Project host this service. However, I understand the importance of avoiding any form of user profiling, so I want to ensure that any potential hosting solution prioritizes user privacy. The code for Tor Watchdog Bot is released under the GPLv3 license, so you are libre to use and modify it as you see fit. I would be thrilled to contribute to the development of this project if it aligns with your vision. Thank you for considering this proposal. I look forward to hearing your thoughts and feedback. Best regards, Aleff. [1] https://github.com/aleff-github/TorWatchdog [2] https://t.me/TorWatchdog_bot --- Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get&search=0x7CFCE404A2168C85 Join to support: - Free Software Foundation! (my.fsf.org/join?referrer=6202114) - Electronic Frontier Foundation! (eff.org) - Tor-Project (torproject.org) - Signal (signal.org)

2 1

Proposal #349: Command state validation (for dropmark attacks)
by Mike Perry 07 Mar '24

07 Mar '24

We've merged a draft of Proposal #349 to torspec: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/349-co… Also available on the tor spec site at: https://spec.torproject.org/proposals/349-command-state-validation.html This proposal is meant to deal with the third class of highly severe protocol side channels in tor: Dropped Cells. See Prop #344 for background: https://spec.torproject.org/proposals/344-protocol-info-leaks.html Note that there still are some details that need to be ironed out wrt how and when to perform checks that depend upon full parsing and protocol context, as opposed to just relay message command. This work is part of Sponsor 112; arti-client support is due by EOY 2024. C-Tor will not implement this proposal. -- Mike Perry

1 0

Fact-checking a claim about relay/bridge fingerprint authentication
by David Fifield 25 Feb '24

25 Feb '24

Cecylia, Arlo, Serene, Shelikhoo, and I are writing a research paper about Snowflake. Here is a draft: https://www.bamsoftware.com/papers/snowflake/snowflake.20231003.e6e1c30d.pdf We're writing to check a factual claim in the section about having multiple backend bridges. Basically, we wanted it to be possible for there to be multiple Snowflake bridge sites run by different groups of people, and we did not want to share the same relay identity keys across all bridge sites, because of the increased risk of the keys being exposed. Therefore every bridge site has its own relay identity, which requires the client to know the relay fingerprints in advance and that it be the client (and not, e.g., the broker) that decides which bridge to use. 1. Is our general description (quoted below) of the design constraints as they bear on Tor correct? 2. Is §4.2 "CERTS cells" the right part of tor-spec to cite to make our point? https://gitlab.torproject.org/tpo/core/torspec/-/blob/b345ca044131b2eb18e6a… https://github.com/turfed/snowflake-paper/blob/e6e1c30dde6716dc5e54a32f2134… A Tor bridge is identified by a long-term identity public key. If, on connecting to a bridge, the client finds that the bridge's identity is not the expected one, the client will terminate the connection \cite[\S 4.2]{tor-spec}. The Tor client can configure at most one identity per bridge; there is no way to indicate (with a certificate, for example) that multiple identities should be considered equivalent. This constraint leaves two options: either all Snowflake bridges must share the same cryptographic identity, or else it must be the client that makes the choice of what bridge to use. While the former option is possible to do (by synchronizing identity keys across servers), every added bridge would increase the risk of compromising the all-important identity keys. Our vision was that different bridge sites would run in different locations with their own management teams, and that any compromise of a bridge site should affect that site only. In my own experiments, providing an incorrect relay fingerprint leads to errors in connection_or_client_learned_peer_id: https://gitlab.torproject.org/tpo/core/tor/-/blob/tor-0.4.7.13/src/core/or/… [warn] Tried connecting to router at 192.0.2.3:80 ID=<none> RSA_ID=2B280B23E1107BB62ABFC40DDCC8824814F80A71, but RSA + ed25519 identity keys were not as expected: wanted 1111111111111111111111111111111111111111 + no ed25519 key but got 2B280B23E1107BB62ABFC40DDCC8824814F80A72 + 1zOHpg+FxqQfi/6jDLtCpHHqBTH8gjYmCKXkus1D5Ko. [warn] Problem bootstrapping. Stuck at 14% (handshake): Handshaking with a relay. (Unexpected identity in router certificate; IDENTITY; count 1; recommendation warn; host 1111111111111111111111111111111111111111 at 192.0.2.3:80)

2 3

Re: [tor-dev] UDP Application Support in Tor
by Vilgot Bergquist 13 Feb '24

13 Feb '24

Hi, I looked at the suggested solutions and I think there is another approach, which is much easier. I C it's pretty easy to encapsulate UDP segments inside TCP segments. Hence there is no need to re-organize the connection logic of tor relays. Instead it should be possible to make Guards, when receiving an UDP packet, to just add a TCP header and then it goes through the normal process. The exit nodes than removed the TCP header and pass the UDP segment on. Regards Vilgot tor-dev-request(a)lists.torproject.org <tor-dev-request(a)lists.torproject.org> schrieb am Donnerstag, 25. Januar 2024 um 18:49: > > > Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. New Proposal - UDP Application Support in Tor > (Micah Elizabeth Scott) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 25 Jan 2024 09:49:02 -0800 > From: Micah Elizabeth Scott beth(a)torproject.org > > To: tor-dev(a)lists.torproject.org > Subject: [tor-dev] New Proposal - UDP Application Support in Tor > Message-ID: 79aa2de8-1ff9-4579-b87f-ee9792e9cbb0(a)torproject.org > > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hello tor-dev folks! > > Late last year I started taking a close look at what it would take to > support applications on Tor which rely on UDP networking. This was > originally to be based on Nick's proposal, 339-udp-over-tor. > > The scope of this work so far has been specifically focused on end-user > application compatibility, and excludes fundamental changes to Tor's > network structure or protocols for now. > > This combination of approach and scope left me with more questions than > answers, so I started looking deeper into the available solutions along > with their expected benefits and risks. This proposal is the result of > that investigation. > > Please find the text attached, or in the torspec repo as proposal #348: > > https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/348-ud… > > Unlike a typical proposal, this does not recommend any specific change > to the Tor implementation. Several possible changes are presented, but > ultimately the recommended approach is to use application-specific UDP > relays to achieve compatibility. > > Integrated approaches are also presented, where Tor does involve itself > in the transit of individual datagrams. These approaches offer > advantages only when they are also part of a long-term plan to offer > transport features beyond those offered by TCP. Until such a plan is > in-scope, specific UDP extensions cannot be offered with confidence. > > I would appreciate any feedback on this proposal, whether it's about > this particular shorter-term context or about longer-term plans to > achieve some kind of optional unreliable transport. > > Thanks for your time! > > --beth >

3 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev