Tor – Arti 1.0.0 is released: Rust Tor implementation ready for production use(blog.torproject.org)
blog.torproject.org
Tor – Arti 1.0.0 is released: Rust Tor implementation ready for production use
https://blog.torproject.org/arti_100_released/
66 comments
It's interesting that the funding for this came from the Zcash Community Grants. There's a lot of money involved with cryptocurrency and a lot of it gets invested into the software involved. It's interesting that in this case, serious money got invested into some software that isn't strictly cryptocurrency-related and is useful outside of cryptocurrency. It makes me wonder if there are other software projects that are generally useful, including but not exclusively to cryptocurrency projects, that could benefit similarly from seeking funding from cryptocurrency projects. Even if one disliked cryptocurrency, this could be seen as getting money redistributed to more useful endeavors to benefit everyone.
iced-rs, a gui framework in rust, is sponsored by kraken.
react-grid-layout is written and maintained by cofounder of bitmex.
uWebSockets, one of the fastest ws servers, is mainly makelt afloat by crypto exchanges who make use of the author‘s consultancy service.
react-grid-layout is written and maintained by cofounder of bitmex.
uWebSockets, one of the fastest ws servers, is mainly makelt afloat by crypto exchanges who make use of the author‘s consultancy service.
I think .attic has benefited from such an event as well:
https://matrix.org/blog/2018/01/29/status-partners-up-with-n...
*matrix
That is probably because Zcash is a privacy tool that just happens to be a cryptocurrency. Snowden was one of the co-founders of the project.
The users are people that rely on the security to stay out of prison, not crypto-bros trying to get rich quick.
The users are people that rely on the security to stay out of prison, not crypto-bros trying to get rich quick.
Snowden was part of the initial ceremony, along with some other crypto experts. Not sure that qualifies him as co-founder
It was a valuable contribution that gave the project a needed boost. The media used the word founder, so I went with that.
This project has come a long way, very fast. Great work to all involved. The biggest security holes in Tor are most likely going to be from the browser going forward.
Hardening the browser is tough, but that's a win for everyone (including those not using Tor).
This sentiment was one that I shared in my Rust work:
> 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.
Hardening the browser is tough, but that's a win for everyone (including those not using Tor).
This sentiment was one that I shared in my Rust work:
> 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.
I have a question, can I use tor as a middleware? for example, can I build a social network with Tor embedded into the client as the network layer?
> Tor embedded into the client
This is the most interesting part of this announcement for me:
>> You can test Arti ... as an embeddable library (if you don't mind a little API instability).
My first thought was adding Tor as a transport for TCP DNS resolution for an existing recursive resolver like unbound. Or, a TOR proxy for DoH public recursive resolvers. Either would result in better privacy than directly using a centralized public resolver with DoH. For the former, you would need to send the query through multiple circuits to have confidence that a guard or an exit node wasn't modifying the query/result (with all exits for a particular query in the same country to minimize geo DNS load balancing causing different results-- this level of control would be easier with a library than a separate daemon communicated through via socks. For the latter, using a socks proxy would work, but the library would make for a simpler setup for the user.
Too bad rust doesn't really do dynamic linking. 'libtor' as a distribution maintained library that is automatically kept patched for security vulnerabilities would add piece of mind when running applications that embed Tor.
This is the most interesting part of this announcement for me:
>> You can test Arti ... as an embeddable library (if you don't mind a little API instability).
My first thought was adding Tor as a transport for TCP DNS resolution for an existing recursive resolver like unbound. Or, a TOR proxy for DoH public recursive resolvers. Either would result in better privacy than directly using a centralized public resolver with DoH. For the former, you would need to send the query through multiple circuits to have confidence that a guard or an exit node wasn't modifying the query/result (with all exits for a particular query in the same country to minimize geo DNS load balancing causing different results-- this level of control would be easier with a library than a separate daemon communicated through via socks. For the latter, using a socks proxy would work, but the library would make for a simpler setup for the user.
Too bad rust doesn't really do dynamic linking. 'libtor' as a distribution maintained library that is automatically kept patched for security vulnerabilities would add piece of mind when running applications that embed Tor.
> Too bad rust doesn't really do dynamic linking.
As far as I remember, you can actually do dynamic linking. But it has its caveats.
Maybe using two different crates, lib-internal and lib-external, where lib-internal compiles to an dylib/so that exposes a C-abi compatible interface. Lib-external it’s just a idiomatic Rust wrapper to that api. It’s a little bit wonky, but I’m pretty sure that it can work.
As far as I remember, you can actually do dynamic linking. But it has its caveats.
Maybe using two different crates, lib-internal and lib-external, where lib-internal compiles to an dylib/so that exposes a C-abi compatible interface. Lib-external it’s just a idiomatic Rust wrapper to that api. It’s a little bit wonky, but I’m pretty sure that it can work.
> It’s a little bit wonky, but I’m pretty sure that it can work.
Not that wonky, it's really a natural consequence of the fact that Rust's stable ABI is the C ABI. Plus you can then use lib-internal from any language that supports FFI to C, not just from Rust.
(Of course, some things just cannot be supported across a dylib boundary, such as arbitrary monomorphized code. But this limitation applies to all such languages; it's why you have "header-only" libraries in C/C++ for example.)
Not that wonky, it's really a natural consequence of the fact that Rust's stable ABI is the C ABI. Plus you can then use lib-internal from any language that supports FFI to C, not just from Rust.
(Of course, some things just cannot be supported across a dylib boundary, such as arbitrary monomorphized code. But this limitation applies to all such languages; it's why you have "header-only" libraries in C/C++ for example.)
Apparently there is a dynamic linking ABI for Rust too, but it is not stable enough to use yet for distros like Debian.
https://wiki.debian.org/StaticLinking#Rust https://lwn.net/Articles/797616/ https://github.com/rust-lang/rfcs/pull/2603
I note that the PR for Rust symbol mangling got merged, but it looks like it isn't the default yet, they are waiting on external tools supporting it.
https://wiki.debian.org/StaticLinking#Rust https://lwn.net/Articles/797616/ https://github.com/rust-lang/rfcs/pull/2603
I note that the PR for Rust symbol mangling got merged, but it looks like it isn't the default yet, they are waiting on external tools supporting it.
>but it is not stable enough
That's the problem. Is still, after all this years, unstable.
Of course you can do dynamic linking without the way that I previously described, but that library will be highly tight to a specific version of the compiler. I think that the biggest problem is dealing with product types for that matter.
Of course you can do dynamic linking without the way that I previously described, but that library will be highly tight to a specific version of the compiler. I think that the biggest problem is dealing with product types for that matter.
Reading through the status tracking bug, it sounds like the ABI is now standardised, but they aren't changing the default to the newly standard ABI yet, because they are waiting on external tools to support it. That said, you could definitely use it today without worrying about the compiler version it seems.
More interesting than a social network is imo applying Tor for IoT. IoT devices suck because they all talk to some mothership and to talk to your own device you have to connect to a third party server. With Tor you can just run a hidden service and the Tor network does all the difficult things for you.
Yes, it's a socks5 proxy, if your software will obey the proxy rules, you can pipe it all through tor.
(as others have pointed out) Yes, indeed: https://github.com/guardianproject/NetCipher/
Absolutely, in the past I was using the proxy that Tor opens and just set up IRC to connect through it. The browser is just one application using it.
> 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.
Amos was right
https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
Amos was right
https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
> 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
> Development of comparable features has gone way faster, even considering that we're building most things for the second time
> Portability has been far easier than C
> We've found that Arti has attracted volunteer contributions in greater volume and with less friction than C Tor
Wow
> Development of comparable features has gone way faster, even considering that we're building most things for the second time
> Portability has been far easier than C
> We've found that Arti has attracted volunteer contributions in greater volume and with less friction than C Tor
Wow
Very cool, I fully support this and I plan to experiment with it. The developers should be proud of making such exciting progress.
But doesn’t “ready for production use” sound like hyperbole when the blog post describes a partially completed implementation? It can’t even connect to onion services yet. Similarly, “improved security” is a suspect claim to make when comparing brand new software to a battle-tested codebase.
There’s no point making claims like that in this phase of early-adopter outreach; it burns future credibility for no reason. We’ll play with the software regardless.
IMO a more accurate claim would be “Arti Tor client, socks proxy and Rust crate can now connect to clearnet hosts through the Tor network, but is still missing some features like bridges and pluggable transports.”
But doesn’t “ready for production use” sound like hyperbole when the blog post describes a partially completed implementation? It can’t even connect to onion services yet. Similarly, “improved security” is a suspect claim to make when comparing brand new software to a battle-tested codebase.
There’s no point making claims like that in this phase of early-adopter outreach; it burns future credibility for no reason. We’ll play with the software regardless.
IMO a more accurate claim would be “Arti Tor client, socks proxy and Rust crate can now connect to clearnet hosts through the Tor network, but is still missing some features like bridges and pluggable transports.”
Agree. While this is certainly a notable milestone it does seem a little premature to celebrate considering the caveats of the current version.
Related:
Arti – An implementation of Tor in Rust - https://news.ycombinator.com/item?id=30683879 - March 2022 (135 comments)
Arti – An implementation of Tor in Rust - https://news.ycombinator.com/item?id=30683879 - March 2022 (135 comments)
A quick search didn't find anything. I wonder, does Arti support communication over a unix domain socket yet?
Using a unix domain socket for a client in a private network namespace with no network interfaces is a nice extra layer to ensure no IP leaks. The regular Tor daemon has supported this for a few years now.
Using a unix domain socket for a client in a private network namespace with no network interfaces is a nice extra layer to ensure no IP leaks. The regular Tor daemon has supported this for a few years now.
There are two instances of `unsafe` in Arti. Both are unnecessary.
1. A mmap'd file is checked to be UTF-8 and then assumed never to change on disk to become non-utf8. https://gitlab.torproject.org/tpo/core/arti/-/merge_requests...
2. A struct holds a raw pointer so it can report an offset into a string later. It should just store the offset. https://gitlab.torproject.org/tpo/core/arti/-/blob/main/crat...
The project has the option to use `tokio`, which contains a staggering amount of unsafe code. I hope nobody distributes prebuilt version of Arti that use tokio.
1. A mmap'd file is checked to be UTF-8 and then assumed never to change on disk to become non-utf8. https://gitlab.torproject.org/tpo/core/arti/-/merge_requests...
2. A struct holds a raw pointer so it can report an offset into a string later. It should just store the offset. https://gitlab.torproject.org/tpo/core/arti/-/blob/main/crat...
The project has the option to use `tokio`, which contains a staggering amount of unsafe code. I hope nobody distributes prebuilt version of Arti that use tokio.
To me this just seems pointless because an implementation in Rust is going to have similar features to one in C, Java, Python, or any of the handful of languages where Tor already exists... I want to rep another project that I think would be more relevant to Tor's goals. It is unfunded yet should it exist: would have the potential to transform privacy on the web. The project is https://github.com/Ayms/node-Tor It's about implementing Tor in Javascript.
Why is this a good idea? Well, if you had a Javascript version of Tor you could quite literally import it on any website. It would be the easiest way to add privacy to millions of users sessions. It would be so ridiculously accessible and easy to use that it would probably lead to rapid innovation in the underlying tech. There is a lot of cool p2p tech already built into the browser that would be an amazing test bed.
Currently Google Chrome are also experimenting with a socket-like API that I believe would be a useful piece of the puzzle [for the project.] It just seems to me that marketing, networking, and being a tech normie is more important than actually having a good idea. So you see pointless projects like this get all the funding while projects like Ayms stay unknown and don't get any. Historical note: the hacker Aaron Swartz (tragically deceased - those who know... know. It was an awful waste) was involved in this project and suggested it as an idea. It's definitely a good one in my opinion.
Why is this a good idea? Well, if you had a Javascript version of Tor you could quite literally import it on any website. It would be the easiest way to add privacy to millions of users sessions. It would be so ridiculously accessible and easy to use that it would probably lead to rapid innovation in the underlying tech. There is a lot of cool p2p tech already built into the browser that would be an amazing test bed.
Currently Google Chrome are also experimenting with a socket-like API that I believe would be a useful piece of the puzzle [for the project.] It just seems to me that marketing, networking, and being a tech normie is more important than actually having a good idea. So you see pointless projects like this get all the funding while projects like Ayms stay unknown and don't get any. Historical note: the hacker Aaron Swartz (tragically deceased - those who know... know. It was an awful waste) was involved in this project and suggested it as an idea. It's definitely a good one in my opinion.
The authors emphasize how the Rust compiler prevented them from introducing many potential bugs.
Sometimes it's better to have no security software and fully understand the implications than to have a security software with bugs unknown to you, which are tacitly exploited by your adversary.
Sometimes it's better to have no security software and fully understand the implications than to have a security software with bugs unknown to you, which are tacitly exploited by your adversary.
This is a stunningly baffling idea given that any user that has half a clue is using Tor with JS disabled.
I see what you're saying. But there's no reason why you couldn't do the same thing with this design. You can build a basic DOM model that is allowed and only let that portion through. While the outer layer uses Javascript freely to run. You can decide what policy you want before displaying any output.
That would have been an amazing project back in 2016 when WASM didn’t exist. Today a js implementation of Tor is pointless.
I don't think that Tor in javascript would improve anything. Tor in golang on the other hand would gain multithreading and ease of integration. It would drop in nicely with the Golang standard library.
A Go version wouldn't improve anything upon the Rust version either. At this scale, Go's simplicity would be a hindrance more than a help, development velocity would suffer compared to Rust. Integration would only be possible in the Go ecosystem, whereas Rust can expose a C API so that Arti can be used (eventually) as the engine for implementations in other languages (Go, Python, JS, etc). Multithreading and overall performance can be better optimized in Rust.
Tor is critical security software with a lot of implementation gotchas. Just like you shouldn't write your own crypto, you shouldn't write your own Tor. Arti is developed by contributors of the original C Tor, I wouldn't go near a Js/Go/whatever implementation from a team with less credentials.
Tor is critical security software with a lot of implementation gotchas. Just like you shouldn't write your own crypto, you shouldn't write your own Tor. Arti is developed by contributors of the original C Tor, I wouldn't go near a Js/Go/whatever implementation from a team with less credentials.
Is this purely rust? Or is there some C code dependencies? If yes, can you share the breakup of language composition in the codebase?
There is some C in the gitlab repo? https://gitlab.torproject.org/tpo/core/arti/-/graphs/main/ch...
But the CONTRIBUTING doesn't say you need to install a C compiler, so probably not? https://gitlab.torproject.org/tpo/core/arti/-/blob/main/CONT...
But the CONTRIBUTING doesn't say you need to install a C compiler, so probably not? https://gitlab.torproject.org/tpo/core/arti/-/blob/main/CONT...
On single C file, 159 lines compared to 83000 lines of Rust. It's used to generate a cert for unittests, not sure why that's not done in Rust.
Rust already depends on LLVM
So ? The fact that rustc compiler uses a component written in C++ doesn't mean that even pure Rust projects have a C++ dependency. Follow any language's bootstrap chain and you'll find C somewhere (or a bootstrapping purists telling you that didn't properly bootstrap the thing), making the "some of the FOOLANG compiler is written in BARLANG" argument pointless.
You don't need a C or C++ compiler (not even Clang) to compile Arti. The rustc packages typically use a vendored version of LLVM.
You don't need a C or C++ compiler (not even Clang) to compile Arti. The rustc packages typically use a vendored version of LLVM.
Does it depend on clang? Because LLVM can't compile C by itself.
How much speed increase can reasonably be expected? I thought bottleneck to Tor is just all the IP relays that occur ?
Their goal was to increase security more than speed.
Yup, the core part of Tor is written in C so it can't get much speedier. Rewriting it in rust is almost is entirely to reduce the footguns you get in C
Might recall reading something to the effect of the C Tor daemon having run into bottlenecks due to lack of multi-threading of certain components and general concern over safety footguns.
Is it purely rust? or some C dependencies are there currently?
Would golang or zig accomplish the same goals too?
It seems the Rust people are especially prone to re implementing things. Nothing is really created, just reimplemented.
I am happy for most software to move from C into almost anything else. Something unlikely to have memory exploits, or with standardized tooling for dependency management and compilation.
Plan9/9front uses C but...
- There are no dynamic binaries. Everything it's static. But binaries and the userland are tiny and usable.
- Cross compile it's dumb easy. [0-9]c, one number per arch.
- Every OS comes with compilers, libraries and sources for every arch.
- Security it's handled by separated modules, a password/login daemon/server and namespaces. Totally different. That will be the future in 10 years, and not Rust.
- There are no dynamic binaries. Everything it's static. But binaries and the userland are tiny and usable.
- Cross compile it's dumb easy. [0-9]c, one number per arch.
- Every OS comes with compilers, libraries and sources for every arch.
- Security it's handled by separated modules, a password/login daemon/server and namespaces. Totally different. That will be the future in 10 years, and not Rust.
I am not sure I can think of something that I more want reimplemented in Rust than Tor. In fact, as excited as I am about Rust inside the kernel, I'm more excited about this and the Rust-ification of Firefox. Given the distro I use, the biggest risks to me are almost guaranteedly through (some) browser.
This was an initiative by the Tor Project itself, in order to make their codebase easier to work on and more secure.
In a way it is nice way to grow Rust ecosystem quickly at-least. Likely makes existing libraries better, and fills up the missing holes in ecosystem. If everyone builds just new stuff, it will likely grow at slower pace, and much smaller ecosystem for libraries.
I'd be fascinated to hear examples of what you think of as "new" and not a reimplmentation. Because the entirety of human history is learning from others, improving it and releasing that as a new invention. All of us stand on the shoulders of giants whenever we do anything.
Databases, text editors, network protocol implementations, GUI frameworks, command line argument parsers, game engines, search engines, build tools - no matter what program is written in any language, there is a program written elsewhere in another language that inspired and informed it.
That's not a knock on the new language, it's just stating a simple fact about human beings.
Databases, text editors, network protocol implementations, GUI frameworks, command line argument parsers, game engines, search engines, build tools - no matter what program is written in any language, there is a program written elsewhere in another language that inspired and informed it.
That's not a knock on the new language, it's just stating a simple fact about human beings.
I think this happens with a lot of languages. The Rust implementations just get more eyeballs and press. Presumably because of the inherent memory safety + speed of (non unsafe) Rust.
So like Unix with C being rewritten in that language instead of the original one written in PDP11 assembler for portability.
Now people rewrites things in Rust for security. It's good, but I think it can be worse; it may make "lazy" programmers and if some bug it's discovered in the Rust runtime, everyone will be equally f*cked.
One of the explicit goals of rust is that it doesn’t have a runtime, so I’m not sure what you mean. If there’s a bug in rustc then we’re about as fucked as a bug in clang or gcc, so I’m not sure how that’s worse.
Rust has a standard library working as something akin to a runtime, period.
https://github.com/rust-lang/rust/blob/33916307780495fe311fe...
Sure, although in this sense C also has a runtime. I assure you there's no magic where CPUs just know that the C main() function is where your program starts. That's what CRT stands for if you see things like "crt0.s" or "crtmain" mentioned, C Run Time.
This Rust code is handing over from your operating system to the main() function of your Rust program, it's arranging that you've got all those modern application amenities like command line parameters, environment variables, it will name your thread (if the OS has names for threads) and so on.
Obviously if your Rust is firmware for $5 device it probably doesn't have an operating system, and it certainly doesn't have command line options, accordingly no_std (the Rust environment you are writing for) doesn't do this stuff. You will wake up alone, with the function you annotated (IIRC with #[start]) running and only the features from Rust's core library. The equivalent in C is standalone mode, C doesn't give you a library at all, just your language, operators etc and your wits. You will of course write your own library unless your project is tiny, because this is pretty unsatisfactory.
However, Arti is not intended to be firmware for a cheap piece of electronics, so both the C Tor implementation and Arti will end up with this very thin runtime to run as applications, the runtime just sets things in motion and calls your main function.
This Rust code is handing over from your operating system to the main() function of your Rust program, it's arranging that you've got all those modern application amenities like command line parameters, environment variables, it will name your thread (if the OS has names for threads) and so on.
Obviously if your Rust is firmware for $5 device it probably doesn't have an operating system, and it certainly doesn't have command line options, accordingly no_std (the Rust environment you are writing for) doesn't do this stuff. You will wake up alone, with the function you annotated (IIRC with #[start]) running and only the features from Rust's core library. The equivalent in C is standalone mode, C doesn't give you a library at all, just your language, operators etc and your wits. You will of course write your own library unless your project is tiny, because this is pretty unsatisfactory.
However, Arti is not intended to be firmware for a cheap piece of electronics, so both the C Tor implementation and Arti will end up with this very thin runtime to run as applications, the runtime just sets things in motion and calls your main function.
and it's worth noting that this isn't hypothetical. the c standard is somewhat unclear and contradictory, and as such no two c compilers fully agree with each other on what the standard actually means.