Network Team Products


  • End-users of Tor: Low-needs privacy-focused
  • End-users of Tor: High-needs privacy-focused
  • End-users of Tor: Censorship-circumventors
  • Researchers analyzing the Tor protocol
  • Programmers working on Tor or compatible implementations of it.
  • Distributors
  • Applications providing complex interactions with Tor
  • Researchers increasing the understanding of the state of the art
  • Programmers repurposing our free software (do you mean botnets?)
  • Directory authority operators
  • Public relay operators
  • Bridge operators
Product Who is/are the lead maintainer(s)? Scope Status Future
Tor nickm Tor is the network daemon that makes Tor clients, relays, directories, and authorities run. Under active development since 2002 or so. Tor 0.3.2 will come out this fall. * In the near-term, there are many proposals in the pipeline that would enhance the Tor protocol.

* We're working on modularizing Tor's design to make it easier to test , easier to sandbox components, and easier to write pieces in simpler languages.

* Ongoing work to improve crypto throughout the Tor protocol.

* Ongoing work to improve path selection throughout the Tor protocol

* Work to improve test coverage throughout Tor daemon.

* Resist DoS better

* Write major components in safer languages

* Remove the leading 0 from the version number

* Drop TLS?

* Better resist traffic-analysis attacks.

* Relay and Onion Service crypto parallelism.

* Improve performance throughout code
Tor Specifications/Proposals nickm (with help from atagar, dgoulet and isis.) * The specifications describe what a program must do to interoperate correctly and safely with Tor clients and relays.

* The proposals each describe a proposed change to the specifications.
The specifications are mostly accurate, but a bit disjointed:

* they haven't received any comprehensive attention for flow since we first wrote them, mostly.

* The older proposals are getting stale; Nick used to write a periodic "what's new, what are the statuses" document, but that hasn't happened in a while.

* We don't have a real change control process on proposals; perhaps we should.
* See if we can't make the specs more accurate and readable

* Switch our protocol descriptions to something a bit more rigorous than the plain-english descriptions we use today?

* Consider a better change-tracking process.

* See if we can't reinstate regular review of the proposals' status.

* Try to move more proposals to accepted/rejected.

* Integrate proposals more quickly
nickm * Trunnel is a set of python scripts that generate human-readable binary-format parsing/unparsing code. * In use for Tor today. Recommended for use with all new binary formats Tor needs to parse/generate. * No current improvements planned.

* Correctness proof might be nice

* Might be nice to make it parse TLS.

* Encourage other protocols to use

* Rigorously document transformations

* Support more languages (WTB C++11 support)

* Fuzzing as a correctness / security check
Tor design documentation:
sjmurdoch, nickm, arma, syverson? * Producing an updated version of the Tor design document, providing an academic-paper-style thing to describe the current Tor network and how it works. Provides more design rationale and less interoperability details than the specs do. * We have a work-in-progress from 2012. * Nick isn't aware of current plans to finish this or keep it up-to-date... but if we did, it would be a solid introduction to Tor's modern structure, and would help academics who haven't been following us for the last 10 years get started in the field.
Tor implementation documentation: nickm * We'd like to cover as much as possible about Tor's current internals and some future plans * nickm is writing this and isn't sure where to put it. * First revision should be finished by end-of-October.

* Future revisions as patches arrive

* We need a maintainance plan for this document, to keep it up-to-date, and make it cover more.
Tor directory authorities Roger? * There are about 9 directory authorities, who need to coordinate running a set of scripts, advertising parameters, banning bad relays, upgrading their authorities, etc etc * Nobody finds the current system easy; scripts are too numerous and hard to run; adding parameters and bad relays is tricky.

* We haven't had a complete outage in years and years.

* There's often one or two authorities acting funny (as in needs-a-kick, not probably-evil)

* It seems to work, mostly|| * We need to get the entire suite of things that we'd like directory authorities to run as tested and maintained as Tor.

* We need to get the entire suite of things we'd like authorities to run easily installed and launched.

* We need to actively work to get directory authority operators happier[[BR]]
* On the politics side, the BadRelay/BadExit process is Entirely Lacking In Transparency from the user base's perspective.
Chutney teor / nickm * Tor test network configuration, launch, connectivity and CPU-limited bandwidth testing. * Creating a user guide.

*[[BR]][[BR]] * Incrementally being improved until it's easier for people to pick up and modify.

*[[BR]][[BR]] * Tested Tor features:

* Authorities, Relays (Exit (IPv4/IPv6), Non-Exit), Bridges (BridgeAuth, Bridge Client (IPv4/IPv6), Bridge Relay (IPv4/IPv6)), Hidden Services

* Networks with a mix of Old/New Tor Versions

* Making multiple connections ($CHUTNEY_CONNECTIONS/$CHUTNEY_HS_MULTI_CLIENT), transporting lots of traffic at once ($CHUTNEY_DATA_BYTES),

* Tor's make test-network-all runs a series of chutney tests and reports PASS/FAIL/SKIP for each (like make check)

* Untested Tor features (currently):

* Bandwidth Weights, Bandwidth Authorities, Pluggable transports, exit policies, failing clients, IPv6 connections (we set up IPv6 bridge clients/bridges/exits, but then use IPv4 addresses)

* Not yet implemented testing features:

* Refactor networks and maybe torrc_templates to make chutney more configurable (chutney 2?)
* Transformed into chutney 2 without losing everything we've learnt in the process.
Hidden Services * asn, dgoulet , nickm anonymous publishing.of data * working.

* very active and growing user base and community.

* many known security issues with the current protocol.

* improvements from SoP, including OnionBalance (trac #14846) and OnioNS (?)
* lots of proposals have been made to improve security (prop224, prop250, prop247)

* all require significant engineering effort, currently unfunded.

* few hidden service developers, and lots of distractions. (All the funded stuff is adding more stuff, and not fixing the security of existing stuff)

* how do we avoid duplication between hidden services, single onion services, and tor2web?

* DoS resilience still needs work.

* ADD_ONION ships in 0.2.7.x which should encourage use.

* Still needs work. (#15588)
Single Onion Services (client-location-hidden, server-location-known services) * dunno, special, teor, hidden services team (?) * client-location-hidden access to data * in proposals/ideas ( - trac #2555)

* multiple experimental prototypes, not based on proposal (Facebook, teor, NRL?)

* one known prototype user (Facebook), not based on proposal (implemented pre-proposal)

* strong desire for performant, authenticated, path-secure (secure-routing?) access to onion sites, with client anonymity (Desire by who? NRL? Spacebook????)

* some known security issues with current hidden services also affect single onion services, but server-side discovery attacks are irrelevant
* interactions with hidden services proposals (prop224, prop250, prop247)

* compatibility with current / future hidden services - open questions on security, engineering, and deployment cost

* research / implementation by NRL

* consideration of load balancing, and geographically-(topologically)-aware load balancing for extra performance

* few hs / onion service developers, and lots of distractions

* how do we avoid duplication between hidden services, single onion services, and tor2web?
tor2web (client-location-known, server-location-hidden services) * virgil? * client access to server-location-hidden data * working.

* active user base and community. (????)

* some known security issues with current hidden services also affect tor2web clients, but client-side discovery attacks are irrelevant
* proposal to improve performance (prop233)

* request to build a tor2web mode-enabled tor binary (trac #15199)

* request to always have tor2web mode compiled-in, and to activate it via a long command-line option -[[BR]][[BR]] * pro: makes deployment easier, con: makes accidental loss of privacy easier

* few hs / onion service developers, and lots of distractions

* how do we avoid duplication between hidden services, single onion services, and tor2web?

* prop227 socks extensions (extended error information was requested by this stuff)
Pluggable Transports * Depends on the PT. Out of the ones maintained by the Tor Project, a combination of asn/dcf/Yawning. Other things maintained by blanu, kpd and mjuarez also exist. But from the Tor perspective, mostly Yawning for now. Providing client access to the Tor network despite censorship, and (sometimes) to serve as a testbed for experimental network protocol things. Depends on the PT. Some deployed and widely used. Some deployed and rarely used. Some experimental and undeployed. Some waiting large scale deployment. PT The Spec: Ongoing efforts to rewrite the existing spec so that other people feel like using it (#10629/#16754). New and Improved spec that fixes everything that's wrong with the current spec (#16755). PT The Protocols: Depends on the PT.... Deprecate: obfs2, flashproxy-nonWebRTC (?), fte (?) Maintain obfs3, ScrambleSuit, meek, obfs4 Deploy: Dust2 (???) Write: flashproxy-WebRTC (???), (YA: I have some extra ideas here, not that I have time these days) PT The Implementation: Fix the logging situation (#9957, #11542) Fix the termination process (#15593) Implement prop227 Implement the New And Improved PT spec PT The Politics: Figure out the deployment process for new PTs (#16756) Come up with a sustainable long term maintenance strategy for PT codebases that don't originate from Tor Developers (No, "Yawning will maintain them all" is not an option here) Figure out how to involve other projects as users of the PT interface (???) (isis and mike have been working on getting the bitcoin devs to accept a BIP for PT/obfsproxy integration into bitcoin nodes, but it doesn't have a number yet) Get more people to write PTs Write stuff that isn't broken, because absolutely everything deployed has feasible attacks. - List of PTs under active development and their maintainers: meek: David Fifield flashproxy: David Fifield (XXX do people still use flashproxy?) pyptlib: ??? obfsproxy: asn? obfs4proxy: Yawning goptlib: ??? Other people: fteproxy (Not our problem????) (agreed) * dust*: blanu (I have no idea what I want to do with this yet) (also agreed)
Bridges (isis doesn't mind being a caretaker of bridges), nickm Special entry guards for censorship circumvention They work. Code is clunky. Heavily depends on TBB, PTs and BridgeDB. :) Code should be refactored into separate module(s), imo. The Bridge reachability and self-reachability code needs redesign and reimplementation due to enumeration attacks. (#7144 ish) Bridges should be able to work without ORPort. (#7349)
BridgeDB Isis Distribute Bridges and PTs to users Doing pretty peachy. Could use more stable funding to make improvements go faster. After said improvements, BridgeDB very likely will need only nominal funding/attention/maintenance. The things described in along with #7250
Shadow Rob discrete-event network simulator testing tor in a network environment * working and maintained.

* currently improving towards supporting 0.2.7 +
* planning to add native instrumentation to tor

* one single developer and maintainer, Rob.
Nyx Damian Provide a command line interface to monitor a local Tor relay or bridge Under use by many Tor relay operators! Quoting Damian: "Nyx is my main focus right now and getting closer to its firstrelease since 2012. Plan is to finish Nyx then focus on Erebus,Cristobal's SoP project to make a relay web dashboard. Presentlythe options we give users in terms of UIs suck. Nyx and Erebus willbe stepping in to fill that gap." Improve user interface. Add features. Make web interface (SoP project). (I'm not Damian!)
Stem Damian Provide easy-to-use parsers for various document formats and protocols within Tor. Quoting Damian: "Stem is feature complete. Its goal was to be a pythonimplementation of the control and directory specifications, and itdoes that. As the backbone of Nyx and Erebus it's naturallyimproving with their development, but not much dedicated focus onStem itself at present."
txtorcon meejah (dawuud is helping out as well i think) Asynchronous Tor controller library written in Twisted Python. Used by OONI and a few other projects. The code is like the most perfect Twisted Python ever written. And 100% test coverage. It's doing awesome. Continued bugfixes and reasonable features. Immediate future: - "tahoe/LAFS" will be using txtorcon -- anything they need - last nit or two for Debian reproducible builds - a higher-level circuit-builder/stream attacher (see - "play more nicely with Stem" (see "optional-stem" branch, should be merged soon) - any features/bugfixes desired by other Tor projects/users
further future: - possibly port to ``txaio`` so it supports asyncio as well as Twisted
carml meejah * command-line thing that uses txtorcon to do fun things with tor.

* plays nicely with grep etc.

* some things you can do: run tor-controller commands, monitor circuits/streams, create/delete circuits,

* download TBB, pastebin/copybin tools, continuously updated xplanet viz. of circuits, ...
* hasn't been tested extensively. * useful for prototyping and experimenting, will add things as I need/want them.
Torsocks * dgoulet * Library that allows a user to run application without Tor support to go over tor. * Maintained. Very little feature development. (YA) #16765 * More features should be added.

* Crazy idea: Windows support.

* IPv6 support, please pretty please?
onionbalance donncha, (asn?) Assists in load balancing busy hidden services. Improve availability by serving hidden service from multiple boxes. Onionbalance alpha was released and was tested by a few volunteers. Seems to work, needs more testing and advertisement. There is a more advanced version in the works, that will be developed over the next months (not part of SoP) Onionbalance as it is, is incompatible with prop246. If we decide to proceed with prop246, we will need to change onionblanace accordingly.
bandwidth authority script aagbsn
meejah is willing to help out here and there, but cycles are (somewhat) scarce
measure bandwidth of relays to include better consensus weights in network status consensus about to be rescued from bit rot Need to incorporate BW scanning in the relatively short run and peer flow in the long run. Bridge bandwidth measurements
Last modified 2 years ago Last modified on Sep 22, 2017, 5:13:33 PM