- tor-dev - lists.torproject.org

When RFC 7686 and transparent proxies collide
by Matt Jolly 28 Sep '24

28 Sep '24

Hello Everyone, I recently inadvertently opened a much larger can of worms than I'd intended when fixing a bug reported downstream where cURL would, when configured with certain DNS backends, fail to resolve .onion addresses. https://bugs.gentoo.org/887287 After doing some digging I discovered that the c-ares library was updated in 2018 to intentionally fail to resolve .onion addresses in line with RFC 7686, and another reported 'Bug' in cURL for leaking .onion DNS requests: https://github.com/c-ares/c-ares/issues/196 https://github.com/curl/curl/issues/543 I took the obviously sane and uncontroversial approach of making sure that cURL would always behave the same way regardless of the DNS backend in use, and that it would output a useful error message when it failed to resolve a .onion address. Unfortunately, this has made a lot of people very angry and been ~~widely regarded as a bad move~~panned by a small subset of downstream cURL users: https://github.com/curl/curl/discussions/11125 https://infosec.exchange/@harrysintonen/110977751446379372 https://gitlab.torproject.org/tpo/core/torspec/-/issues/202 I accept that, in particular, transproxy users are being inconvenienced, but I also don't want to go back to 'cURL leaks .onion DNS requests _sometimes_'. As a career sysadmin and downstream bug triager: this is the stuff that keeps me up late at night. Quite literally, far too often. I have found, however that the downstreams that I expected to be inconvenienced most (Whonix and Tails) simply use socks: https://github.com/Kicksecure/sdwdate/commit/5724d83b258a469b7a9a7bbc651539… https://github.com/Kicksecure/tb-updater/commit/d040c12085a527f4d39cb1751f2… https://github.com/Kicksecure/usability-misc/blob/8f722bbbc7b7f2f3a35619a5a… https://gitlab.tails.boum.org/tails/tails/-/issues/19488 https://gitlab.tails.boum.org/tails/tails/-/merge_requests/1123 I've asked in the Tor Specifications issue (inspired by Silvio's suggestions), and in the cURL issue, but I seem to be getting nowhere and the impacted users are clamouring for a quick band-aid solution, which I feel will work out worse for everyone in the long run: >How can client applications (safely): > >1.discover that they're in a Tor-enabled environment >2.resolve onion services only via Tor in that circumstance >3.not leak .onion resolution attempts at all > >Right now, not making these requests in the first place is the >safest (and correct) thing to do, however inconvenient it may be. >Rather than immediately trying to come up with a band-aid approach >to this problem, a sane mechanism needs to be implemented to: > >1.prevent each application from coming up with their own solution >2.prevent inconsistency in .onion resolution (i.e. no "oh it only >leaks if DO_ONION_RESOLUTION is set") >3.provide a standardised mechanism for applications that want to be Tor >aware to discover that they're in a Tor-enabled environment. I'm not particularly attached to that last point, but it's worth discussing. On a related note: -is the use of a transparent proxy recommended? -is there a sane alternative that involves as minimal configuration as possible for these users? I'm not sure what the best way forward is here, but I'm hoping that actual Tor developers might have a useful opinion on the matter, or at least be able to point me in the right direction. Thanks for your time, Cheers, Matt

7 9

Proposal 351: Making SOCKS5 authentication extensions extensible
by Nick Mathewson 16 Sep '24

16 Sep '24

(You can see this proposal rendered at https://spec.torproject.org/proposals/351-socks-auth-extensions.html ) ``` Filename: 351-socks-auth-extensions.md Title: Making SOCKS5 authentication extensions extensible Author: Nick Mathewson Created: 9 September 2024 Status: Open ``` ## Introduction Currently, Tor implementations use the SOCKS5 username and password fields to pass parameters for stream isolation. (See the `IsolateSocksAuth` flag in the C tor manual, and the "Stream isolation" section ([forthcoming](https://gitlab.torproject.org/tpo/core/torspec/-/merge_request…) in our [socks extensions](../socks-extensions.md) spec.) > Tor implementations also support SOCKS4 and SOCKS4a, > but they are not affected by this proposal. > > The C Tor implementation also supports other proxy types besides SOCKS. > They are not affected by this proposal > because they either have other means to extend their protocols > (as with HTTP headers in HTTP CONNECT) > or no means to pass extension information > (as for DNS proxies, iptables transparent proxies, etc). Until now, the rules for interpreting these fields have been simple: all values are permitted, and streams with unequal values may not share a circuit. But in order to integrate SOCKS connections into Arti's RPC protocol, we additionally want the ability to send RPC "Object IDs"[^ObjectId] in these fields. To do this, we will need some way to tell when we have received an object ID, when we have received an isolation parameter, and to avoid confusing them with one another. > Note that some confusion will necessarily remain possible: > Since current Tor clients are allowed to send any value > as SOCKS username and password, > any value we specify here will be one which a client in principle > _might_ have sent under the old protocol. Additionally, since we are adding complexity to the interpretation of these fields, it's possible we'll want to change this complexity in the future. To do this, we'll want a versioning scheme to premit changes. ## Proposal > If accepted, the following can be incorporated into > our [socks extensions](../socks-extensions.md) spec.) We support a series of extensions in SOCKS5 Username/Passwords. Currently, these extensions can encode a stream isolation parameter (used to indicate that streams may share a circuit) and an RPC object ID (used to associate the stream with an entity in an RPC session). These extensions are in use whenever the SOCKS5 Username begins with the 8-byte "magic" sequence `[3c 74 6f 72 53 30 58 3e]`. (This is the ASCII encoding of `<torS0X>`). If the SOCKS5 Username/Password fields are present but the Username does not begin with this byte sequence, it indicates _legacy isolation_. New client implementations SHOULD NOT use legacy isolation. A SocksPort may be configured to reject legacy isolation. When these extensions are in use, the next byte of the username after the "magic" sequence indicate a version number. Any implementation receiving an unrecognized or missing version MUST reject the socks request. When the version number is `[30]` (the ascii encoding of `0`), we interpret the rest of the Username field and the Password field as follows: The remainder of the Username field encodes an RPC Object ID. (If the remainder of the Username field is empty, there is no RPC object.) The Password field is stream isolation parameter. If it is empty, the stream isolation parameter is an empty string. ### Stream isolation > This replaces the corresponding part of > the "Stream isolation" section > ([forthcoming](https://gitlab.torproject.org/tpo/core/torspec/-/merge_request…) > in our [socks extensions](../socks-extensions.md) spec. Two streams are considered to have the same SOCKS authentication values if and only if one of the following is true: - They are both SOCKS4 or SOCKS4a, with the same user "ID" string. - They are both SOCKS5, with no authentication. - They are both SOCKS5 with USERNAME/PASSWORD authentication, using legacy isolation parameters, and they have identical usernames and identical passwords. - They are both SOCKS5 using the extensions above, with the same stream isolation parameter. ### A further extension for integration with Arti SOCKS > We should add the following to a specification, > though it is not clear whether it goes in the Arti RPC spec > or in the socks extensions spec. In some cases, the RPC Object ID may denote an object that already includes information about its intended stream isolation. In such cases, the stream isolation MUST be blank. Implementations MUST reject non-blank stream isolation in such cases. In some cases, the RPC object ID may denote an object that already includes information about its intended destination address and port. In such cases, the destination address MUST be `0.0.0.0` or `::` (encoded either as an IPv4 address, an IPv6 address, or a hostname) and the destination port MUST be 0. Implementations MUST reject other addresses in such cases. ----- > (Here the specifications end. > The rest of this proposal is discussion.) ## Design considerations Our use of SOCKS5 Username/Passwords here (as opposed to some other, new authentication type) is based on the observation that many existing SOCKS5 implementations support Username/Password, but comparatively few support arbitrary plug-in authentication. The magic "`<torS0X>`" prefix is chosen to be 8 characters long so that existing client implementations that generate random strings will not often generate it by mistake. The version number is chosen to be an ASCII `0` rather than a raw 0 byte, for compatibility with existing SOCKS5 client implementations that do not support non-ASCII username/password values. ## C Tor migration When this proposal is accepted, we *should* configure C tor to implement it as follows: - To reject any SOCKS5 Username starting with `<torS0X>` unless it is exactly `<torS0X>0`. This behavior is sufficient to give correct isolation behavior, to reject any connection including an RPC object ID, and to reject any as-yet-unspecified isolation mechanisms. [^ObjectId]: An ObjectId is used in the Arti RPC protocol to associate a SOCKS request with some existing Client object, or with a preexisting DataStream.

6 10

changes in user-agent spoofing in the Tor Browser 14.0 series
by Morgan 09 Sep '24

09 Sep '24

tldr; We're planning on disabling HTTP-header user agent spoofing on the basis that it (in our analysis) does little if any good while causing breakage on the internet when the JS and HTTP user agents do not match. However, if there is something critical we're missing here, we'd certainly love to hear. In the meantime it seems like an easy win for some improved usability. best, -morgan Excerpt from 14.0a4's blog post follows: > User Agent Spoofing Changes > > Historically, Tor Browser has spoofed the browser user agent found in HTTP headers, while not spoofing the user agent returned by the Navigator.userAgent property in JavaScript. The logic behind the HTTP header spoofing was to prevent passive tracking of users' operating system by websites (when using the 'Safest' security level) and by malicious exit nodes (or their upstream routers) passively listening in on unencrypted HTTP traffic. We left the JavaScript query intact for the purposes of website compatibility and usability. We also left it enabled because there are already many ways of detecting a user's real operating system when JavaScript is enabled (e.g. via font enumeration). > > With Tor Browser 14.0a4, we have introduced the boolean preference privacy.resistFingerprinting.spoofOsInUserAgentHeader. When this pref is set to true (which is currently the default), Tor Browser will follow the previously described legacy behaviour. However, if you set this preference (accessible in about:config) to false, Tor Browser will never spoof the user agent and will report your operating system family (i.e. Windows, macOS, Linux, or Android) when requested. We are considering changing Tor Browser to make this the new default behaviour. > > So, why are we considering making this change? Basically, asymmetrically spoofing the user agent causes website breakage seemingly due to bot-detection scripts. And (in our analysis) it also provides only a negligible amount of benefit to the user in terms of additional linkability (i.e. cross-site tracking, fingerprinting) protections, and only then when JavaScript is disabled. Tor Browser's default HTTPS-Only mode (and much of the web having moved to HTTPS) has also significantly reduced the utility of passively sniffing HTTP traffic for user agents as well. > > We would be very curious to hear from users and domain experts as to whether user agent spoofing is providing any other privacy benefits. In the meantime, disabling spoofing is available to users on an opt-in basis. For more information and to join the conversation, please see the Gitlab ticket tor-browser#42467.

1 0

Proposal for a New Web App to Configure Tor Nodes
by Alessandro Greco 30 Aug '24

30 Aug '24

Hello everyone, I have been thinking about creating a web app that generates a script to configure a Tor node based on the settings defined by the user. Let me explain a bit further. This web app could work either entirely on the client side using JavaScript or on the server side. I believe a client-side-only approach is preferable because it avoids handling user data in any way and reduces the risk of man-in-the-middle attacks, although it doesn't completely eliminate it. The main use case would be for a user who wants to contribute by configuring a Tor node. Instead of manually writing all the various configurations — from downloading Tor to following the best practices after configuration — the user would simply need to select a series of options on a user-friendly page (user-friendly = easier setup => more wish to do it, which could realistically lead to more relays), download the auto-generated file, and run it with administrative privileges. I believe that developing such a web app could not only benefit the Tor network by encouraging the deployment of new nodes, but it could also be highly educational. Alongside the script to execute, a standard report could be generated to technically explain the function of each setting. Of course, there would be a standard section allowing for basic relay execution and an "advanced" section that opens up multiple functionalities for the user. I'm not sure if something like this already exists, but I think it could be very helpful. For instance, I often find myself scrolling through the manual to check for the latest updates applicable to the `torrc` file. With this web app, we could also create a "latest updates" section. This is just my rough idea, and if it proves useful not just for me but for the rest of the community as well, we could consider structuring a development project around it. Best regards, Aleff. --- 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)

5 6

terminology explaination: identifier.
by eff_03675549＠posteo.se 27 Aug '24

27 Aug '24

Hi, On the following URL : http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/stats… the quote: *All per-graph statistics files are available for download via an URL of the form:* *https://metrics.torproject.org/identifier.csv* Remains ambiguous to me... *object of this email: *What is an /identifier/ ? Do the author imply the Nickname / Fingerprint ?... Do they imply the |KP_relayid_ed| that requires specific relay permission when the mere fingerprint is safer ?... *Would you kindly increment the torproject webpage with an example (or a set of examples) @ *http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/stats.html Cheers, Carlos.

2 1

Cancel
by tj 21 Aug '24

21 Aug '24

Sent from my iPhone

2 1

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