🛠We should migrate this information (whatever part of it is still accurate) to pages on the developer portal. I have reformatted it to be readable, but haven't updated it to refer to current reality.
—nickm, 14 August 2020
Network Team Products
WHO USES THESE TOOLS?
- 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.
- 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
Maintainer: network team
Status: active since 2002 or so.
Tor is the network daemon that makes Tor clients, relays, directories, and authorities run.
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
Better resist traffic-analysis attacks.
Relay and Onion Service crypto parallelism.
Improve performance throughout code
Maintainer: Network team
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
Status: Stable, in use in Tor today.
Trunnel is a set of python scripts that generate human-readable binary-format parsing/unparsing code.
- 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
Maintainer: nickm?, arma?, sjmurdoch?, syverson?
Status: Old versions released; new versions stalled.
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.
- 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 directory authorities
Maintainer: Roger, dirauth operators Status: Live
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.
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!
On the politics side, the BadRelay/BadExit process is Entirely Lacking In Transparency from the user base's perspective. ||
Maintainer: nickm, network team Status: in use for testing
Tor test network configuration, launch, connectivity and CPU-limited bandwidth testing.
We need a user guide https://trac.torproject.org/projects/tor/wiki/doc/TorChutneyGuide
Incrementally being improved until it's easier for people to pick up and modify.
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.
Maintainers: asn, dgoulet, network team Status: Working
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) ||
Maintainer: asn, dgoulet, network team Status: Implemented
Client-location-hidden access to data
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?
Maintainers: None Status: Deprecated, unsupported, probably not working.
Tor2web was a web frontend to onion services.
Maintainers: Network Team, Anticensorship team Status: Transitioned to anticensorship team
Primary responsibility for pluggable transport development now rests with the anticensorship team. The network team maintains the core in
tor that launches and uses pluggable transports. Both teams are jointly responsible for Tor's pluggable transport specification (?).
Maintainers: Network Team, Anticensorship team Status: Stable, in production
The network team maintains the code in
tor that uses bridges, and runs as a bridge. The anticensorshop team is responsible for the network of bridges as a whole. Both teams are jointly responsible for changes in the design of bridge behavior.
Maintainers: Anticensorship team Status: In production, currently under rewrite
Responsibility for bridgedb moved to the anticensorship team, and they are rewriting it.
Maintainers: Rob, jnewsome Status: Working and maintained
A discrete-event network simulator for testing Tor's network performance and behavior.
Maintainers: atagar Status: Working, maintained, stable.
Command-line text interface for monitoring a local tor relay or bridge.
Maintainers: atagar Status: Feature-complete, under active maintenance, used in production
Python library to provide easy-to-use parsers for various document formats and protocols within Tor. Used to implement many Tor controller programs.
Maintainers: meejah Status: Stable, under active development, used in production
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."
- "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 https://github.com/meejah/txtorcon/issues/125)
- "play more nicely with Stem" (see "optional-stem" branch, should be merged soon)
- any features/bugfixes desired by other Tor projects/users
- possibly port to !
txaio!so it supports asyncio as well as Twisted
Maintainer: meejah Status: In development?
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, ...
Maintainer: dgoulet Status In use, needs maintenance.
Library that allows a user to run application without Tor support to go over tor.
- Improved IPv6 support