Opened 4 years ago

Closed 3 years ago

Last modified 16 months ago

#17270 closed task (implemented)

Evaluate non-C tor implementations for hackability

Reported by: nickm Owned by: nickm
Priority: Medium Milestone: Tor: 0.2.8.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: 028-triage, 201511-deferred, TorCoreTeam201601, 201512-deferred
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor: SponsorS

Description

For testing, we should have badly-behaved clients and servers. But implementing that in C seems like horrible overkill. Let's look at the best-of-breed compatible implementations, and figure out which one would be the best basis for making a bunch of stub test client/servers.

(It's okay if the client answer and the server answer aren't the same)

Child Tickets

Change History (13)

comment:1 Changed 4 years ago by nickm

Keywords: TorCoreTeam201511 added

comment:2 Changed 4 years ago by teor

Severity: Normal

Name: Gareth Owen's Tor Research Framework
URL: https://github.com/owenson/tor-research-framework
Role: Client
Hackability: High (I contributed to it in 2014)

However, it has been used as part of his HS hashring research, not sure if we want that association. (But that functionality might help in testing banning for hashring crawling. Not sure if the hashring crawling part is publicly available or in this repository, though.)

comment:3 Changed 4 years ago by teor

Name: haskell-tor
URL: https://github.com/GaloisInc/haskell-tor
Role: Client (no hidden service support)
Hackability: unknown

Just mentioned on the tor-dev mailing list.

comment:5 Changed 4 years ago by teor

From tor-dev@:

python + Scapy:
https://github.com/cea-sec/TorPylle

...and, based on the above, this:
https://github.com/pycepa/pycepa

"I haven't tried either of the above. I also recall a Python + Twisted
one, too, but I can't find it now."

comment:7 Changed 3 years ago by nickm

Keywords: TorCoreTeam201512 201511-deferred added; TorCoreTeam201511 removed

Bulk-move uncompleted items to december. :/

comment:8 Changed 3 years ago by nickm

Owner: set to nickm
Status: newaccepted

Okay, I guess I'm reviewing the code on these...

comment:9 Changed 3 years ago by nickm

Keywords: TorCoreTeam201601 201512-deferred added; TorCoreTeam201512 removed

Perhaps in January?

comment:10 Changed 3 years ago by nickm

Evaluating super quickly and unfairly. A unicode confused face (😕) indicates that I don't actually know the language too well.

  • haskell-tor looks solidly written and nicely terse. A little less documentation than I'd prefer. But if you don't know haskell it won't be a walk in the park.😕
  • purpleonion : 7 years outdated.😕
  • gotor: Clean but far less documented than I'd prefer. In a nice language at least, and easy to follow.😕
  • node-tor: Far less documented than I'd prefer. 😕No commits for a year?
  • TorPylle: 2.5 years out of date. Far less documented than I'd prefer. No ntor support.
  • pycepa: Documented! Pythonic, mostly! Appears not to be a complete client implementation though; there are hardwired node identities in Circuit.py. We'll have to see how much of this is actually implemented. Not sure it actually checks signatures. Looks pretty hackable. GPLv3.
  • oppy: Documentd in some places; undocmented in others. Uses Twisted. Doesn't validate all signatures. Clean. Looks pretty hackable. 3BSD licensed.
  • orchid: Far less documented than I'd like. Very nice code structure though. Very big complete implementation. Last commit around May 2015? 3BSD license.
  • tor-research-framework: Far less documented than I'd like. Good documentation in some places though. Not in love with architecture/hackability; looks procedural at first glance. GPL3+ license.
  • silvertunnel-ng: Documentation present but uneven. Pretty big implementation; pretty complete. GPL2+ license.

comment:11 Changed 3 years ago by yawning

Every once in a while I feel tempted to dust off the gotor code and clean it up/update it....

comment:12 Changed 3 years ago by nickm

Resolution: implemented
Status: acceptedclosed

Okay, I'm going to call this done. Please reopen if you want to do more evaluation.

comment:13 Changed 16 months ago by teor

Stem now has ORPort support for downloading descriptors:
https://lists.torproject.org/pipermail/tor-dev/2018-February/012905.html

This support is based on Endosome:
https://github.com/teor2345/endosome

Both are eminently hackable.
(I used endosome to review tor-spec against the actual C relay implementation.)

This list is kept up to date:
https://trac.torproject.org/projects/tor/wiki/doc/ListOfTorImplementations

Note: See TracTickets for help on using tickets.