Back in 2020, we started work on a new implementation of the Tor
protocols in the Rust programming language. Now we believe it’s ready
for wider use.
In this blog post, we’ll tell you more about the history of the Arti
project, where it is now, and where it will go next.
Background: Why Arti? And How?
Why rewrite Tor in Rust? Because despite (or because of) its
maturity, the C Tor implementation is showing its age. While C was a
reasonable choice back when we started working on Tor 2001, we’ve
always suffered from its limitations: it encourages a needlessly
low-level approach to many programming problems, and using it safely
requires painstaking care and effort. Because of these limitations,
that pace of development in C has always been slower than we would
have liked.
What’s more, our existing C implementation has grown over the years to
have a not-so-modular design: nearly everything is connected to
everything else, which makes it even more difficult to analyze the
code and make safe improvements.
A movement to Rust seemed like a good answer. Started in 2010 at
Mozilla, and now maintained by the Rust Foundation, Rust has grown
over the years to become an independently maintained programming
language with great ergonomics and performance, and strong safety
properties. In 2017, we started experimenting with adding Rust inside
the C Tor codebase, with a view to replacing the code bit by bit.
One thing that we found, however, was that our existing C code was not
modular enough to be easily rewritten. (Rust’s security guarantees
depend on Rust code interacting with other Rust code, so to get any
benefit, you need to rewrite a module at a time rather than just one
function at a time.) The parts of the code that were isolated enough
to replace were mostly trivial, and seemed not worth the
effort—whereas the parts that most needed replacement were to
intertwined with each other to practically disentangle. We tried to
disentangle our modules, but it proved impractical to do so without
destabilizing the codebase.
So in 2020, we started on a Rust Tor implementation that eventually
became Arti. At first, it was a personal project to improve my Rust
skills, but by the end of the summer, it could connect to the Tor
network, and by September it sent its first anonymized traffic. After
some discussion, we decided to adopt Arti as an official part of the
Tor Project, and see how far we could take it.
Thanks to generous support from Zcash Community Grants starting in
2021, we were able to hire more developers and speed up the pace of
development enormously. By October, we had our first “no major
privacy holes” release (0.0.1), and we started putting out monthly
releases. In March of this year, we had enough of a public API to be
confident in recommending Arti for experimental embedding, and so we
released version 0.1.0.
And now, with our latest release, we’ve reached our 1.0.0 milestone.
Let’s talk more about what that means.
Arti 1.0.0: Ready for production use
When we defined our set of milestones, we defined Arti 1.0.0 as “ready for
production use”: You should be able to use it in the real world, to get a
similar degree of privacy, usability, and stability to what you would with a
C client Tor. The APIs should be (more or less) stable for embedders.
We believe we have achieved this.
You can now use arti proxy to connect to the Tor network
to anonymize your network connections.
Note that we don’t recommend pointing a conventional web browser
at arti (or, indeed, C Tor):
web browsers leak much private and identifying information.
To browse the web anonymously, use Tor Browser;
we have instructions for using it with Arti.
Recent work
To achieve this, we we’ve made many improvements to Arti.
(Items marked as NEW are
new or substantially improved since last month’s 0.6.0 release.)
- We’ve improved robustness of bootstrapping, including some cases where
our client could get confused and stuck, or put itself into an infinite
loop. To do this, we build a stress-tester for various failure scenarios,
and evaluated Arti’s performance in those scenario. - We’ve added a robust mechanism to report our bootstrapping status so
that applications can detect and help diagnose problems. - We’ve profiled our performance along various metrics, and worked to address
those that were out-of-line. - Our APIs are far more stable and well analyzed than six months ago.
- We’ve done a lot of work to future-proof our configuration system.
- We now have the same client-oriented security improvements as the C Tor
implementation, including:- Property-oriented circuit isolation.
- Validating file permissions to ensure data is stored safely.
- Omission of sensitive information from logs. NEW
- Wiping keys from memory after they’re used. NEW
- Hardening against debugger-based attacks. NEW
- Channel padding to resist netflow-based traffic analysis. NEW.
- We have improved our portability on iOS, Android, and Windows. NEW
For a complete list of changes, including a list of just the changes
since 0.6.0, see our CHANGELOG.
So, how’s Rust been?
Our experience with Rust has been a definite success.
At every stage,
we’ve encountered way fewer bugs than during comparable C development.
The bugs that we have encountered have almost all been
semantic/algorithmic mistakes (real programming issues),
not mistakes in using the Rust language and its facilities.
Rust has a reputation for being a difficult language with a picky compiler –
but the pickiness of the compiler has been a great boon.
Generally speaking, if our Rust code compiles and passes its tests, it is much likelier to be correct than our C code under the same conditions.
Development of comparable features has gone way faster, even
considering that we’re building most things for the second time. Some
of the speed improvement is due to Rust’s more expressive semantics
and more usable library ecosystem—but a great deal is due to the
confidence Rust’s safety brings.
Portability has been far easier than C, though sometimes we’re forced
to deal with differences between operating systems. (For example,
when we’ve had to get into the fine details of filesystem permissions,
we’ve found that most everything we do takes different handling on
Windows.)
One still-uncracked challenge is binary size. Unlike C’s standard
library, Rust’s standard library doesn’t come installed by default on
our target systems, and so it adds to the size of our downloads.
Rust’s approach to high-level programming and generic code
can make fast code, but also large executables.
We’ve been able to offset this somewhat with the Rust ecosystem’s
improved support for working with platform-native TLS implementations,
but there’s more work to do here.
Embedding has been practical so far. We have preliminary work
embedding Arti in both Java and Python.
We’ve found that Arti has attracted volunteer contributions in greater
volume and with less friction than C Tor.
New contributors are greatly assisted by
Rust’s strong type system,
excellent API documentation support,
and safety properties.
These features help them find where to make a change,
and also enable making changes to unfamiliar code
with much greater confidence.
What’s coming next?
Our primary focus in Arti 1.1.0 will be to implement Tor’s
anticensorship features, including support for bridges and pluggable
transports. We’ve identified our primary architectural challenges
there, and are working through them now.
In addition, we intend to further solidify our compliance with
semantic versioning in our high-level arti-client crate. We are
confident that our intentionally exposed APIs there are stable, but
before we can promise long-term stability we need to make sure that we
have a way to detect and prevent changes to the lower-level APIs that
arti-client re-exports. The cargo-public-api and
cargo-semver-checks crates both seem promising, but we may need
additional thinking.
(This semantic versioning difficulty is the primary reason why
arti-client is still at 0.6.0 instead of 1.0.0. When we declare
1.0.0 for arti-client, we want to be sure that we can keep backward
compatibility for as long as possible.)
We expect that Arti 1.1.0 will be complete around the end of October.
We had originally estimated one month of the team’s time for this
work, but since we’ll all be off for a week for a meeting, and then a
few of us have vacations, it seems that we’ll need to allocate two
months in order to find a month of hacking time. (Such is life!)
And then?
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.
We’ve applied to the Zcash Community Grants for funding to support these next two
phases, and we’re waiting hopefully to see what they say.
And after that?
We intend that, in the long run, Arti will replace our C tor
implementation completely, not only for clients, but also for relays
and directory authorities. This will take several more years of work,
but we’re confident that it’s the right direction forward.
(We won’t stop support for the C implementation right away; we expect
that it will take some time for people to migrate.)
How can you try Arti now?
We rely on users and volunteers to find problems in our software and
suggest directions for its improvement. You can test Arti as a SOCKS
proxy (if you’re willing to compile from source) and as an embeddable
library (if you don’t mind a little API instability).
Assuming you’ve installed Arti (with cargo install arti, or directly
from a cloned repository), you can use it to start a simple SOCKS proxy
for making connections via Tor with:
$ arti proxy -p 9150
and use it more or less as you would use the C Tor implementation!
(It doesn’t support onion services yet. If compilation doesn’t work,
make sure you have development files for libsqlite installed on your
platform.)
If you want to build a program with Arti, you probably want to start with the arti-client crate. Be sure to check out the examples too.
For more information, check out the README file. (For now, it assumes that you’re comfortable building Rust programs from the command line). Our CONTRIBUTING file has more information on installing development tools, and on using Arti inside of Tor Browser. (If you want to try that, please be aware that Arti doesn’t support onion services yet.)
When you find bugs, please report them on our bugtracker. You can request an account or report a bug anonymously.
And if this documentation doesn’t make sense, please ask questions!
The questions you ask today might help improve the documentation
tomorrow.
Whether you’re a user or a developer, please give Arti a try, and let
us know what you think. The sooner we learn what you need, the better
our chances of getting it into an early milestone.
Acknowledgments
Thanks to everybody who has helped take us here from Arti 0.1.0,
including: 0x4ndy, Alexander Færøy, Alex Xu, Arturo Marquez,
Christian Grigis, Dimitris Apostolou, Emptycup, FAMASoon,
feelingnothing, Jim Newsome, Lennart Kloock, Michael, Michael Mccune,
Neel Chauhan, Orhun Parmaksız, Richard Pospesel, Samanta Navarro,
solanav, spongechameleon, Steven Murdoch, Trinity Pointard, and
Yuan Lyu!
And, of course, thanks to Zcash Community Grants for their support
of this critical work! The Zcash Community Grants program (formerly known as ZOMG) funds independent teams entering the Zcash ecosystem to perform major ongoing development (or other work) for the public good of the Zcash ecosystem. Zcash is a privacy-focused cryptocurrency, which pioneered the use of zk-SNARKs. The Zcash ecosystem is driven to further individual privacy and freedom.