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/196https://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/11125https://infosec.exchange/@harrysintonen/110977751446379372https://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/19488https://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
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
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
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
