[tor-dev] Alternative Implementations of Tor

[George Kadianakis]

Alexander Færøy <ahf at 0x90.dk> writes:

> [ text/plain ]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hello.
>
> Over the past year I've been hacking, on and off, on an implementation
> of Tor in the Erlang programming language. The project started out after
> I met Linus Nordberg at the Erlang User Conference in the summer of 2015
> - -- a couple of weeks before the CCC Camp in Germany. Linus and I
> discussed what it would take to get a very basic implementation of a Tor
> relay up and running in Erlang.
>
> The project has been named Talla, which is still open for change --
> especially if it collides with an already established project within the
> wider Tor development community. I was unable to find any name clashes
> myself, but I may very well have overlooked something.
>
> The parts of Talla that is implemented in "pure" Erlang is going to be
> licensed under a two-clause BSD license. Talla also contains a "module"
> which is using Tor's ed25519 ref10 implementation (Thanks to Yawning for
> a great amount of help there) -- that module is licensed under the same
> license as Tor itself.
>
> I'm now at the point where things are slowly starting to take form. The
> important pieces of the code have so far been kept available only to a
> tiny group of close friends that I trust not to share the code until I,
> and possibly other people, considers that the code is stable enough for
> the wilderness of the wider internet.
>
> There is, to my knowledge, currently only one implementation of Tor that
> is actively in use on the production network, which is the C
> implementation. I'm aware of a Haskell implementation made by Galois,
> which to me mostly seemed like it was designed to be building blocks for
> writing more specialized clients and doing research with the Tor
> network. Last time I looked, the Haskell implementation's main function
> was doing a DNS lookup through a circuit within the Tor network and then
> quitting. I was also told there had been an implementation in Go that
> have had activity on the production network, but that project was
> abandoned by its maintainer.
>
> In general I'm a bit uncertain about the "best practices" of dealing with a
> third party Tor implementation, which Talla is.
>
> I'm writing this email to receive suggestions, comments, and possibly
> creative ideas about the following:
>
> 1. What is the general criteria set from the Tor project's perspective
>    on when it is acceptable to make alternative Tor implementations
>    available to the general public?
>
>    I'm currently testing Talla using Chutney with a mixture of NTOR and
>    pre-NTOR Tor daemons running (inspired by one of the configuration
>    files in the Chutney repository, which referred to a 'tor-old'
>    binary).
>
>    My current plan is to stabilize Talla further until my gut feeling is
>    that I can try to announce a single, middle, relay to the production
>    Tor network. This relay will, of course, have a platform-string set
>    to something easily identifiable like "Talla 0.0.1 (...)" and the
>    contact-string set to a valid method of reaching out to me with, in
>    its announced server descriptor. I will closely monitor that things
>    are going as I expect and probably turn it off shortly after the
>    test, when I have seen that my code isn't too "crashy" -- this will
>    most likely be repeated a number of times until I'm satisfied with
>    the results.
>
>    Could I do more to ensure that the people caring for the network as a
>    whole wont fear me pressing the start-button here?
>
> 2. I will not do any classical releases (as in packagable .tar.gz) until
>    I'm past the point where my gut feelings are telling me that my code is
>    reasonably stable for the production network of Tor.
>
>    I will, in a very visible location, request that no distribution
>    developers makes any packages of the code until there is a release.
>
>    I think this is already the norm, but I guess being explicit won't
>    hurt.
>
> 3. I will write, also in a visible location, a warning that the code is
>    not production ready and that people should probably stick to running a
>    Tor relay using the official Tor daemon and point to the installation
>    instructions on torproject.org.
>
> 4. Not have any installation documentation and hope that Erlang is still
>    an esoteric enough language to make people pass by without trying :-)
>
> 5. Talla will not have any references to the directory authorities that
>    are currently used for the Tor production network. This means that
>    anyone who is interested in running Talla will have to explicitly set
>    the directory authority servers in Talla's configuration file.
>
>    This will allow people who want to toy around with it together with
>    Chutney to be easily able to do that.
>
> Why am I asking all these questions now, when I could just wait until
> Talla is ready? In two weeks there will be a smaller hacker camp in
> Denmark, named BornHack, where I was planning on giving a talk on the
> development of Talla, the design of the Erlang application, some of the
> many refactoring periods there have been, general information about how
> Tor works, and the testing of Talla. At the same time of the
> presentation I want to make all of the code for Talla available for the
> audience and public to see even though it at this point is not ready for
> "production usage" on the public Tor network.
>

Sounds great! Looking forward to see Talla in action!

It seems like you are already aware of the security issues of alternative
implementations and you have good ideas on how to discourage random people from
using your early implementations for sensitive reasons. So I'm not going to
touch much on that (although installation documentation will be helpful if you
want external contributors (which you probably do)).

> I hope this email will also allow us to discuss the wider concept of a
> network where there exists multiple implementations and the consequences
> of that. It might be there are other people hacking on a Tor
> implementation in their favourite language :-)
>

Here are some thoughts on alternative implementations. Maybe they are helpful.

a) I think it's quite important to have a precise scope in mind for your
   alternative Tor implementation, otherwise you might get lost in the
   complexity.

   What do you hope Talla to become and who do you imagine to be your users?

   It's easy to say that you want Talla to be a _complete_ implementation of
   the Tor protocol, but that's ultra hard to achieve in any sort of reasonable
   timeframe.  Both because the Tor protocol is big and complicated, and also
   because the codebase has many many undocumented subsystems that will bite if
   you don't implement them properly (e.g. guards, stats, replay attacks, etc.)

   I think a plausible way to develop and deploy alternative implementations
   would be to _hyperfocus_ on specific areas of Tor, build them to completion
   and actually get them deployed. For example, your alternative implementation
   could focus on being a relay. This way you don't need to care about how
   clients, TBB or dirauths work for the most part.

   After you finish one area, you can move on to the next. Although I suspect
   that every Tor area is so intricate that there will be enough work for a
   while if you hope to reach feature parity with tor.

   Here are some examples of functionality that alternative implementations
   could focus on completing:
     dirauth, client, relay, hidden service, bridge authority

   For example, I feel that dirauths could be a good target for alternative
   implementations. They are small, they don't share much code with clients and
   relays, and it would be great if they run memory-safe code.  They are also
   run by knowledgeable folks, so they would be able to configure an
   alternative implementation (however they are all paranoid, so you would have
   to be very persuasive).

b) Another benefit I see in alternative Tor implementations is that they could
   be used to test and strengthen our main codebase (little-t-tor).

   For example, alternative implementations could be used as integration tests
   for little-t-tor.

   Also, alternative implemenations could provide insight on how little-t-tor's
   modules should be designed. We have great plans for modularizing
   little-t-tor further, specifying precise interfaces for modules and
   rewriting parts of Tor in other languages. I think alternative
   implementations could help us with designing those submodules, and perhaps
   we could even use portions of the alt implementations as little-t-tor
   submodules themselves.

c) Since the Montreal hackfest we have a Tor testnet to test various
   experimental features (e.g. prop250). I think it would be great testing for
   Talla to join that network and participate as a relay (or as a
   client/dirauth). Don't be afraid about breaking stuff!

   Please get in touch with David so that you get added to the list :)

Have fun developing Talla! :)