en/volunteer.wml (9f030aa21) - tor-webwml.git

volunteer.wml

## translation metadata
# Revision: $Revision$

#include "head.wmi" TITLE="Tor: Volunteer"

<h2>Three things everyone can do now:</h2>
<ol>
<li>Please consider <a href="<page docs/tor-doc-relay>">running
a relay</a> to help the Tor network grow.</li>
<li>Tell your friends! Get them to run relays. Get them to run hidden
services. Get them to tell their friends.</li>
<li>We are looking for funding and sponsors. If you like Tor's goals, please
  <a href="<page donate>">take a moment to donate to support further
  Tor development</a>. Also, if you know any
  companies, NGOs, agencies, or other organizations that want communications
  security, let them know about us.</li>
</ol>

<a id="Usability"></a>
<h2><a class="anchor" href="#Usability">Supporting Applications</a></h2>
<ol>
<li>We need good ways to intercept DNS requests so they don't "leak" their
request to a local observer while we're trying to be anonymous. (This
happens because the application does the DNS resolve before going to
the SOCKS proxy.)</li>
<li>Tsocks/dsocks items:
<ul>
<li>We need to <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TSocksPatches">apply
all our tsocks patches</a> and maintain a new fork. We'll host it if
you want.</li>
<li>We should patch Dug Song's "dsocks" program to use Tor's
<i>mapaddress</i> commands from the controller interface, so we
don't waste a whole round-trip inside Tor doing the resolve before
connecting.</li>
<li>We need to make our <i>torify</i> script detect which of tsocks or
dsocks is installed, and call them appropriately. This probably means
unifying their interfaces, and might involve sharing code between them
or discarding one entirely.</li>
</ul>
</li>
<li>People running relays tell us they want to have one BandwidthRate
during some part of the day, and a different BandwidthRate at other
parts of the day. Rather than coding this inside Tor, we should have a
little script that speaks via the <a href="<page gui/index>">Tor
Controller Interface</a>, and does a setconf to change the bandwidth
rate.  There is one for Unix and Mac already (it uses bash and cron),
but Windows users still need a solution.
</li>
<li>Tor can <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">exit
the Tor network from a particular exit node</a>, but we should be able
to specify just a country and have something automatically pick. The
best bet is to fetch Blossom's directory also, and run a local Blossom
client that fetches this directory securely (via Tor and checking its
signature), intercepts <tt>.country.blossom</tt> hostnames, and does
the right thing.</li>
<li>Speaking of geolocation data, somebody should draw a map of the Earth
with a pin-point for each Tor relay. Bonus points if it updates as the
network grows and changes. Unfortunately, the easy ways to do this involve
sending all the data to Google and having them draw the map for you. How
much does this impact privacy, and do we have any other good options?</li>
</ol>

<a id="Documentation"></a>
<h2><a class="anchor" href="#Documentation">Documentation</a></h2>
<ol>
<li>Please help Matt Edman with the documentation and how-tos for his
Tor controller,
<a href="http://vidalia-project.net/">Vidalia</a>.</li>
<li>Evaluate and document
<a href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO">our
list of programs</a> that can be configured to use Tor.</li>
<li>We need better documentation for dynamically intercepting
connections and sending them through Tor. tsocks (Linux), dsocks (BSD),
and freecap (Windows) seem to be good candidates, as would better
use of our new TransPort feature.</li>
<li>We have a huge list of <a href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms">potentially useful
programs that interface to Tor</a>. Which ones are useful in which
situations? Please help us test them out and document your results.</li>
<li>Help translate the web page and documentation into other
languages. See the <a href="<page translation>">translation
guidelines</a> if you want to help out. We especially need Arabic or
Farsi translations, for the many Tor users in censored areas.</li>
</ol>

<a id="Coding"></a>
<a id="Summer"></a>
<a id="Projects"></a>
<h2><a class="anchor" href="#Projects">Good Coding Projects</a></h2>
<ol>

<li>
Reanimate one of the approaches to implement a Tor client in Java,
e.g. the <a href="http://onioncoffee.sourceforge.net/">OnionCoffee
project</a>, and make it run on <a
href="http://code.google.com/android/">Android</a>. The first step
would be to port the existing code and execute it in an Android
environment. Next, the code should be updated to support the newer Tor
protocol versions like the <a href="<svnsandbox>doc/spec/dir-spec.txt">v3
directory protocol</a>. Further, support for requesting or even
providing Tor hidden services would be neat, but not required. The
student should be able to understand and write new Java code, including
a Java cryptography API. Being able to read C code would be helping,
too. The student should be willing to read the existing documentation,
implement code based on it, and, if required, refine the documentation
if things are underdocumented. This project is mostly about coding and
to a small degree about design.
</li>

<li>
Write a tool that runs automatic system tests in addition
to the existing unit tests. The Java-based Tor simulator <a
href="https://tor-svn.freehaven.net/svn/puppetor/trunk/">PuppeTor</a>
might be a good start for starting up a private Tor network, using it
for a while, and verifying that at least parts of it are working. This
project requires to conceive a blueprint for performing system tests
of private Tor networks, before starting to code. Typical types of
tests range from performing single requests over the private network to
manipulating exchanged messages and see if nodes handle corrupt messages
appropriately. The student should be able to obtain a good understanding
of how Tor works and what problems and bugs could arise to design good
test cases. Understanding the existing Tor code and documentation is
vital. If PuppeTor is used, the student should also be able to understand
and possibly extend an existing Java application. This project is partly
about design and partly about coding.
</li>

<li>
Implement a <a href="http://www.ss64.com/bash/top.html">top-like</a>
management tool for Tor relays. The purpose of such a tool would be
to monitor a local Tor relay via its control port and include useful
system information of the underlying machine. When running this tool, it
would dynamically update its content like top does for Linux processes.
<a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">This
or-dev post</a> might be a good first read. The student should be familiar
with or willing to learn about administering a Tor relay and configuring
it via its control port. As an initial prototype is written in Python,
some knowledge about writing Python code would be helpful, too. This
project is for the one part about identifying requirements to such a
tool and designing its interface; but on the other part, the project
also requires a lot of coding.
</li>

<li>Help Mike Perry on his <a
href="https://www.torproject.org/svn/torflow/">TorFlow</a>
library (<a href="https://www.torproject.org/svn/torflow/TODO">TODO</a>):
it's a python library that uses the <a
href="https://www.torproject.org/svn/torctl/doc/howto.txt">Tor controller
protocol</a> to instruct Tor to build circuits in a variety of ways,
and then it measures performance and tries to detect anomalies.</li>
<li>Torflow / soat to detect bad relays and automatically get that
info to the directory authorities for realtime blacklisting</li>
<li>Torstatus. Set up an automated system for tracking network health
over time, graphing it, etc. Better metrics for assessing network
health and growth.</li>
<li>vidalia and upnp</li>
<li>nymble</li>

<li>
Help port <a
href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> to
Windows. 1) handle spaces in path names and understand the filesystem
namespace &mdash; namespace meaning where application data, personal data,
and program data typically reside in various versions of Windows. 2) the
ability to handle ipv6 communications. 3) the ability to asynchronously
query name servers, find the system nameservers, and manage netbios
and dns queries. 4) use native regex capabilities of Windows, rather
than using 3rd party GNU regex libraries. 5) manage events and buffers
natively (i.e. in Unix-like OSes, Polipo defaults to 25% of ram, in
Windows it's whatever the config specifies). 6) some sort of GUI config
and reporting tool, bonus if it has a systray icon with right clickable
menu options. Double bonus if it's cross-platform compatible.
</li>

<li>
a way to generate the website diagrams from source, so we can translate
them as utf-8 text rather than with gimp. (svg? or imagemagick?)
integrate this with a wml file so translations are easy and images are
generated in multiple languages at web publish
</li>

<li>How can we make the <a
href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
easier to maintain, improve, and document?</li>
<li>We need a distributed testing framework. We have unit tests,
but it would be great to have a script that starts up a Tor network, uses
it for a while, and verifies that at least parts of it are working.</li>

<li>Don't like any of these? Look at the <a
href="<svnsandbox>doc/design-paper/roadmap-future.pdf">Tor development
roadmap</a> for more ideas.</li>
<li>Don't see your idea here? We probably need it anyway! Contact
us and find out.</li>
</ol>

<h2><a class="anchor" href="#Coding">Coding and Design</a></h2>
<ol>
<li>Tor relays don't work well on Windows XP. On
Windows, Tor uses the standard <tt>select()</tt> system
call, which uses space in the non-page pool. This means
that a medium sized Tor relay will empty the non-page pool, <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">causing
havoc and system crashes</a>. We should probably be using overlapped IO
instead. One solution would be to teach <a
href="http://www.monkey.org/~provos/libevent/">libevent</a> how to use
overlapped IO rather than select() on Windows, and then adapt Tor to
the new libevent interface. Christian King made a
<a href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">good
start</a> on this last summer.</li>
<li>We need to actually start building our <a href="<page
documentation>#DesignDoc">blocking-resistance design</a>. This involves
fleshing out the design, modifying many different pieces of Tor, adapting
<a href="http://vidalia-project.net/">Vidalia</a> so it supports the
new features, and planning for deployment.</li>
<li>We need a flexible simulator framework for studying end-to-end
traffic confirmation attacks. Many researchers have whipped up ad hoc
simulators to support their intuition either that the attacks work
really well or that some defense works great. Can we build a simulator
that's clearly documented and open enough that everybody knows it's
giving a reasonable answer? This will spur a lot of new research.
See the entry <a href="#Research">below</a> on confirmation attacks for
details on the research side of this task &mdash; who knows, when it's
done maybe you can help write a paper or three also.</li>
<li>Tor 0.1.1.x and later include support for hardware crypto accelerators
via OpenSSL. Nobody has ever tested it, though. Does somebody want to get
a card and let us know how it goes?</li>
<li>Perform a security analysis of Tor with <a
href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Determine
if there are good fuzzing libraries out there for what we want. Win fame by
getting credit when we put out a new release because of you!</li>
<li>Tor uses TCP for transport and TLS for link
encryption. This is nice and simple, but it means all cells
on a link are delayed when a single packet gets dropped, and
it means we can only reasonably support TCP streams. We have a <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">list
of reasons why we haven't shifted to UDP transport</a>, but it would
be great to see that list get shorter. We also have a proposed <a
href="<svnsandbox>doc/spec/proposals/100-tor-spec-udp.txt">specification
for Tor and
UDP</a> &mdash; please let us know what's wrong with it.</li>
<li>We're not that far from having IPv6 support for destination addresses
(at exit nodes). If you care strongly about IPv6, that's probably the
first place to start.</li>
</ol>

<a id="Research"></a>
<h2><a class="anchor" href="#Research">Research</a></h2>
<ol>
<li>The "website fingerprinting attack": make a list of a few
hundred popular websites, download their pages, and make a set of
"signatures" for each site. Then observe a Tor client's traffic. As
you watch him receive data, you quickly approach a guess about which
(if any) of those sites he is visiting. First, how effective is
this attack on the deployed Tor codebase? Then start exploring
defenses: for example, we could change Tor's cell size from 512
bytes to 1024 bytes, we could employ padding techniques like <a
href="http://freehaven.net/anonbib/#timing-fc2004">defensive dropping</a>,
or we could add traffic delays. How much of an impact do these have,
and how much usability impact (using some suitable metric) is there from
a successful defense in each case?</li>
<li>The "end-to-end traffic confirmation attack":
by watching traffic at Alice and at Bob, we can <a
href="http://freehaven.net/anonbib/#danezis:pet2004">compare
traffic signatures and become convinced that we're watching the same
stream</a>. So far Tor accepts this as a fact of life and assumes this
attack is trivial in all cases. First of all, is that actually true? How
much traffic of what sort of distribution is needed before the adversary
is confident he has won? Are there scenarios (e.g. not transmitting much)
that slow down the attack? Do some traffic padding or traffic shaping
schemes work better than others?</li>
<li>The "routing zones attack": most of the literature thinks of
the network path between Alice and her entry node (and between the
exit node and Bob) as a single link on some graph. In practice,
though, the path traverses many autonomous systems (ASes), and <a
href="http://freehaven.net/anonbib/#feamster:wpes2004">it's not uncommon
that the same AS appears on both the entry path and the exit path</a>.
Unfortunately, to accurately predict whether a given Alice, entry,
exit, Bob quad will be dangerous, we need to download an entire Internet
routing zone and perform expensive operations on it. Are there practical
approximations, such as avoiding IP addresses in the same /8 network?</li>
<li>Other research questions regarding geographic diversity consider
the tradeoff between choosing an efficient circuit and choosing a random
circuit. Look at Stephen Rollyson's <a
href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">position
paper</a> on how to discard particularly slow choices without hurting
anonymity "too much". This line of reasoning needs more work and more
thinking, but it looks very promising.</li>
<li>Tor doesn't work very well when relays have asymmetric bandwidth
(e.g. cable or DSL). Because Tor has separate TCP connections between
each hop, if the incoming bytes are arriving just fine and the outgoing
bytes are all getting dropped on the floor, the TCP push-back mechanisms
don't really transmit this information back to the incoming streams.
Perhaps Tor should detect when it's dropping a lot of outgoing packets,
and rate-limit incoming streams to regulate this itself? I can imagine
a build-up and drop-off scheme where we pick a conservative rate-limit,
slowly increase it until we get lost packets, back off, repeat. We
need somebody who's good with networks to simulate this and help design
solutions; and/or we need to understand the extent of the performance
degradation, and use this as motivation to reconsider UDP transport.</li>
<li>A related topic is congestion control. Is our
current design sufficient once we have heavy use? Maybe
we should experiment with variable-sized windows rather
than fixed-size windows? That seemed to go well in an <a
href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">ssh
throughput experiment</a>. We'll need to measure and tweak, and maybe
overhaul if the results are good.</li>
<li>To let dissidents in remote countries use Tor without being blocked
at their country's firewall, we need a way to get tens of thousands of
relays, not just a few hundred. We can imagine a Tor client GUI that
has a "Tor for Freedom" button at the top that opens a port and relays a
few KB/s of traffic into the Tor network. (A few KB/s shouldn't be too
much hassle, and there are few abuse issues since they're not being exit
nodes.) But how do we distribute a list of these volunteer clients to the
good dissidents in an automated way that doesn't let the country-level
firewalls intercept and enumerate them? Probably needs to work on a
human-trust level. See our <a href="<page documentation>#DesignDoc">early
blocking-resistance design document</a> and our
<a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#BlockingResistance">FAQ
entry</a> on this, and then read the <a
href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship">censorship
resistance section of anonbib</a>.</li>
<li>Tor circuits are built one hop at a time, so in theory we have the
ability to make some streams exit from the second hop, some from the
third, and so on. This seems nice because it breaks up the set of exiting
streams that a given relay can see. But if we want each stream to be safe,
the "shortest" path should be at least 3 hops long by our current logic, so
the rest will be even longer. We need to examine this performance / security
tradeoff.</li>
<li>It's not that hard to DoS Tor relays or directory authorities. Are client
puzzles the right answer? What other practical approaches are there? Bonus
if they're backward-compatible with the current Tor protocol.</li>
</ol>

<a href="<page contact>">Let us know</a> if you've made progress on any
of these!

</div>

#include <foot.wmi>

tor-webwml.git

two idea sketches from phobos