Paying some attention to Arti.
“Rust is more secure than C. Despite our efforts, it’s all too simple to
mess up when using a language that does not enforce memory safety. We
estimate that at least half of our tracked security vulnerabilities would
have been impossible in Rust, and many of the others would have been very
unlikely.”
and also think of how it could replace the current Tor C implementation, in a “safe” way, eventually.
After Arti 1.1.0, we’re going to focus on onion services in Arti 1.2.0. They’re a complex and important part of the Tor protocols, and will take a significant amount of effort to build. Making onion services work securely and efficiently will require a number of related protocol features, including support for congestion control, DOS protection, vanguards, and circuit padding machines.
After that, Arti 2.0.0 will focus on feature parity with the C tor client implementation, and support for embedding Arti in different languages. (Preliminary embedding work is promising: we have the beginnings of a VPN tool for mobile, embedding Arti in Java.) When we’re done, we intend that Arti will be a suitable replacement for C tor as a client implementation in all (or nearly all) use contexts.
Until a Debian package being available from deb.torproject.org and feature support such as onions and TransPort will probably take a while.
Quote David Goulet on Tor Project issue tracker:
It is not even clear that
artiwill actually have a ControlPort as we know it.
Quote Arti 1.1.5 is released: Onion Services, RPC, and a security patch | The Tor Project
work on a new RPC API (a successor to C Tor’s “control port”) that will give applications a safe and powerful way to work with Arti without having to write their code in Rust or link Arti as a library (unless they want to).
We probably shouldn’t wait to port to Arti until it fully replaces C-Tor. That would leave users using potentially unmaintained or less-maintained code for however long it takes us to port, which could take a long time depending on the complexity of everything. However, we can’t start porting until we have at least a bare minimum feature set. I went through our code and pieced together things from varying bits of documentation about Arti, this is what I currently think we’d need Arti to do versus what it already does.
/usr in Whonix-Gateway 18, so I’m not sure if that will continue to work.enable_http_connect setting, SOCKS proxy ports also double as HTTP proxy ports. I don’t expect this will be a problem for us.arti:new_isolated_client, any streams created with this “client” will not be shared with any other “client”. This then gives you an ObjectID that you can apparently “use as the target of a SOCKS stream” (I’m guessing that means that you can pass it as a username as documented here?), so presumably you could use that to force a new stream to be built to check if stream building works at all. But you (maybe?) need to initiate a connection to some online service via that ObjectID, which would probably be undesirable and unreliable…
arti:get_client_status returns (among other things) a ready boolean, maybe this is more reliable than the equivalent that C-Tor provided?arti:get_client_status.arti:get_client_status’s ready return may be useful here too.SIGNAL NEWNYM, needed by tor-control-panel/usr/lib/python3/dist-packages/tor_control_panel/tor_control_panel.py at master · Kicksecure/tor-control-panel · GitHub). This doesn’t seem to be supported.tor-ctrl will end up going away; this is basically a Bash adapter for using the Tor control protocol more easily. If we need something like this for the Arti RPC protocol, we’ll probably need to use their RPC client library via Python and turn that into something you can access from Bash. The sub-programs of tor-ctrl mentioned above however should ideally keep working.It’s worth noting that not all functionality that we previously used Tor’s control port for needs to be implemented in Arti; there is a feature of Arti that will hot-reload its configuration file if it notices a change, so we could implement our own cross-VM communications channel for making whitelisted changes to Arti’s config in a safe manner for things like setting up onion services.
Another question is how onion-grater would work with this. Arti might not need onion-grater anymore, since its RPC mechanism has the concept of a “superuser” mode and privileged and unprivileged commands. Depending on what is considered unprivileged, we might be able to just allow the workstation to directly access Arti, but not give it whatever it needs to run superuser-level commands. Note that right now no superuser-level RPC commands are implemented, or at least that’s what the docs say.
In summary, I think I could probably get a proof-of-concept made that uses Whonix with Arti; the basics would work, probably everything that uses the control port would not work. It’s not to the point where we could migrate to it though, even if we did have a deb package for it. It looks like it’s heading down a trajectory that will work for us eventually.
Great!
Not important. History:
Tor can now serve as http proxy - HTTPTunnelPort
Some applications use Tor control protocol. Most of them are opt-in and related to their use of Tor onion. One exception is Tor Browser, which uses this for signal newnym.
Not a blocker as this feature is broken also in C-Tor. History:
Connect to public Tor network by default / avoid Anon Connection Wizard (ACW) popup at first boot
See also:
We’re using Tor 0.4.9.8 according to Nyx on my sys-whonix VM, so I think we’re safe there.
True, I was going to mention that but then forgot.