volunteer.html (f782ad695) - tor-webwml.git

volunteer.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
  <title>Tor: Volunteer</title>
  <meta name="Author" content="Roger Dingledine" />
  <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
  <link rel="stylesheet" type="text/css" href="stylesheet.css" />
  <link rel="shortcut icon" type="image/x-icon" href="/favicon.ico" />
</head>
<body>

<table class="banner" border="0" cellpadding="0" cellspacing="0">
    <tr>
        <td class="banner-left"></td>
        <td class="banner-middle">
            <a href="index.html">Home</a>
          | <a href="overview.html">Overview</a>
          | <a href="download.html">Download</a>
          | <a href="documentation.html">Docs</a>
          | <a href="support.html">Support</a>
          | <a href="faq.html">FAQs</a>
          | <a class="current">Volunteer</a>
          | <a href="developers.html">Developers</a>
          | <a href="research.html">Research</a>
          | <a href="people.html">People</a>
        </td>
	<td class="banner-right">
		<a href="/"><img src="/images/en.png" alt="English" /></a>
		<a href="/index.it.html"><img src="/images/it.png" alt="Italiano" /></a>
		<a href="/index.de.html"><img src="/images/de.png" alt="Deutsch" /></a> 
	</td>
    </tr>
</table>

<h2>Seven things everyone can do now:</h2>
<ol>
<li> We need users like you to try Tor out, and let the Tor developers know about bugs you find or features you don't find.</li>
<li> Please consider <a href="/cvs/tor/doc/tor-doc-server.html">running a server</a> to help the Tor network grow.</li>
<li> We especially need people with Windows programming skills to run an exit server on Windows, to help us debug.</li>
<li> Run a <a href="/cvs/tor/doc/tor-hidden-service.html">Tor hidden service</a> and put interesting content on it.</li>
<li> Take a look at the <a href="/gui/">Tor GUI Competition</a>, and come up with ideas or designs to contribute to making the Tor interface better. Free T-shirt for each submission!</li>
<li> Tell your friends! Get them to run servers. Get them to run hidden services. Get them to tell their friends.</li>
<li> Consider joining the <a href="http://secure.eff.org/tor">Electronic Frontier Foundation</a>. More EFF donations means more freedom in the world, including more Tor development.</li>
</ol>

<h2>Usability and Installers</h2>
<ol>
<li>Make an entry to the <a href="/gui/">GUI competition</a>. This
requires looking at how Tor interacts with the operating system and
other applications, deciding where the critical usability issues are,
and trying to make an application (or applet or plugin) that helps the
user experience.</li>
<li>Extend our NSIS-based windows installer to include FreeCap and/or
Privoxy. When we ship Privoxy, include a config file that's preconfigured
to work well with Tor.</li>
<li>Develop a way to handle OS X installation and uninstallation.</li>
<li>Choosing exit node by meta-data, e.g. country.</li>
<li>Tor provides anonymous connections, but if you want to keep multiple
pseudonyms in practice (say, in case you frequently go to two websites
and if anybody knew about both of them they would conclude it's you), we
don't support that well yet. We should find a good approach and
interface for handling pseudonymous profiles in Tor. See <a
href="http://archives.seul.org/or/talk/Dec-2004/msg00086.html">this
post</a> and <a href="http://archives.seul.org/or/talk/Jan-2005/msg00007.html">followup</a> for details.</li>
</ol>

<h2>Coding, Design, and Software Development</h2>
<ol>
<li>We need a better option for a scrubbing web proxy than
just Privoxy, since it's unmaintained and still has bugs, especially
on Windows. While we're at it, what sensitive information is not
kept safe by Privoxy? Are there other scrubbing web proxies that are
more secure?</li>
<li>We need better applications for dynamically intercepting
connections and sending them through Tor. tsocks (Linux) and freecap
(Windows) seem to be good candidates, and there are a variety of other
possibilities listed at the bottom of <a href="/support.html">our support
page</a>.</li>
<li>Speaking of tsocks, it appears to be unmaintained: we have submitted
several patches with no response. Can somebody volunteer to start
maintaining a new tsocks branch? We'll help.</li>
<li>We need a way to intercept DNS requests so they don't "leak" while
we're trying to be anonymous. One option is to use Tor's built-in
support for doing DNS resolves; but you need to ask via our new socks
extension for that, and so no applications do this yet. Another option
is to use Tor's controller interface: the application connects to Tor,
hands it the DNS query, and Tor replies with a dummy IP address. Then
the application makes a connection through Tor to that dummy IP address,
and Tor automatically maps it back to the original query.</li>
<li>Right now the hidden service descriptors are being stored on just a few
directory servers. This is bad for privacy and bad for robustness. To get
more robustness, we're going to need to make hidden service descriptors
even less private because we're going to have to mirror them onto many
places. Ideally we'd like to separate the storage/lookup system from the
Tor directory servers entirely. Any reliable distributed storage system
will do, as long as it allows authenticated updates. As far as we know,
no implemented DHT code supports authenticated updates. What's the right
next step?</li>
<li>Tor exit servers need to do many DNS resolves in parallel. But
gethostbyname() is poorly designed --- it blocks until it has finished
resolving a query --- so it requires its own thread or process. So
Tor is forced to spawn many separate DNS "worker" threads. There are
some asynchronous DNS libraries out there, but traditionally they are
buggy and abandoned. There are rumors that some of them are becoming
better. Are any of them stable, fast, clean, and free software? If
so (or if we can make that so), we should integrate them into Tor
so we don't need to spawn dozens of dns resolver threads. See <a
href="http://archives.seul.org/or/talk/Sep-2005/msg00001.html">Agl's
post</a> for a potential start.</li>
<li>Currently Tor ships with its own AES, since when we started OpenSSL
had missing/broken AES support. But now that it's gotten more mainstream,
we should change things so we only use our bundled AES if OpenSSL doesn't
support it natively.</li>
<li>Because Tor servers need to store-and-forward each cell they handle,
high-bandwidth Tor servers end up using dozens of megabytes of memory
just for buffers. We need better heuristics for when to shrink/expand
buffers. Maybe this should be modelled after the Linux kernel buffer
design, where you have many smaller buffers that link to each other,
rather than monolithic buffers?</li>
<li>How do ulimits work on Win32, anyway? We're having problems
especially on older Windowses with people running out of file
descriptors, connection buffer space, etc. (We should handle
WSAENOBUFS as needed, look at the MaxConnections registry entry,
look at the MaxUserPort entry, and look at the TcpTimedWaitDelay
entry. We may also want to provide a way to set them as needed. See <a
href="http://bugs.noreply.org/flyspray/index.php?do=details&amp;id=98">bug
98</a>.)</li>
<li>Encrypt identity keys on disk, and implement passphrase protection
for them. Right now they're just stored in plaintext.</li>
<li>Periodically people running servers 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="/gui/">Tor
Controller Interface</a>, and does a setconf to change the bandwidth
rate. Perhaps it would run out of cron, or perhaps it would sleep
until appropriate times and then do its tweak (that's probably more
portable). Can somebody write one for us and we'll put it into <a
href="/cvs/tor/contrib/">tor/contrib/</a>?</li>
<li>Patches to Tor's autoconf scripts. First, we'd like our configure.in
to handle cross-compilation, e.g. so we can build Tor for obscure
platforms like the Linksys WRTG54. Second, we'd like to make with-ssl-dir
disable the search for ssl's libraries.</li>
<li>Implement reverse DNS requests inside Tor (already specified in
Section 5.4 of <a href="/cvs/tor/doc/tor-spec.txt">tor-spec.txt</a>).</li>
<li>Perform a security analysis of Tor with <a
href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Determine
if there 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>How hard is it to patch bind or a DNS proxy to redirect requests to
Tor via our tor-resolve socks extension? What about to convert UDP DNS
requests to TCP requests and send them through Tor?</li>
</ol>

<h2>Documentation</h2>
<ol>
<li>Volunteer to help maintain this website: code, content, css,
layout.</li>
<li>We have too much documentation --- it's spread out too much and
duplicates itself in places.</li>
<li>Help translate the web page and documentation into other
languages.  See the <a href="translation.html">translation
guidelines</a> if you want to help out.</li>
<li>Investigate privoxy vs. freecap vs. sockscap for win32 clients. Are
there usability or stability issues that we can track down and
resolve?</li>
<li>Evaluate, create, and <a
href="http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO">document
a list of programs</a> that can be routed through Tor.</li>
<li>We have a huge list of <a href="/support.html"> potentially useful
programs to interface to Tor</a>. Which ones are useful in which
situations? Please help us test them out and document your results.</li>
</ol>

<h2>Research</h2>
<ol>
<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 "help China" 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.</li>
<li>Tor doesn't work very well when servers 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>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. Do this attack on the
deployed Tor network, and find out how effective it is. 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 compare traffic signatures and become convinced
that we're watching the same stream. 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>Come up with practical approximations to picking entry and exit in
    different routing zones.</li>
<li>Find ideal churn rate for helper nodes; how safe is it?</li>
<li>Is exiting from the middle of the circuit always a bad idea?</li>
<li>IPv6 support (For exit addresses)
<li>It's not that hard to DoS Tor servers or dirservers. Are puzzles the
right answer? What other practical approaches are there?</li>
</ol>

Drop by the #tor IRC channel at irc.oftc.net or email tor-volunteer@freehaven.net if you want to help out!

</div>
</div>
  <div class="bottom" id="bottom">
     <i><a href="mailto:tor-webmaster@freehaven.net" class="smalllink">Webmaster</a></i> -
     $Id$
  </div>
</body>
</html>

<li>Have NULL_REP_IS_ZERO_BYTES default to 1.</li>
<li>Implement preservation of reputation through reboots for clients
and dirservers.</li>
<li>Add in support egd or other non-OS-integrated strong entropy sources.</li>
<li>Implement a way to get autoconf to install things into ~/.tor.</li>
<li>Change server descriptors to declare log level.</li>
<li>Add in support for clients to avoid servers that are too loggy based upon user configuration of acceptable log level.</li>
<li>Separate node discovery from routing to allow neat extensions.  [Goodell?]

<ul>
<li>Add SetServerStatus control event to adjust verified/running status of nodes.</li>
<li>Add NoDownload config option to prevent regular directory downloads from happening.</li>
</ul>
</li>

<li>Use cpuworker for more heavy lifting.</li>
<ul>
<li>Signing (and verifying) hidserv descriptors</li>
<li>Signing (and verifying) intro/rend requests</li>
<li>Signing (and verifying) router descriptors</li>
<li>Signing (and verifying) directories</li>
<li>Doing TLS handshake (this is very hard to separate out, though)</li>
</ul>

<li>Buffer size pool: allocate a maximum size for all buffers, not a maximum size for each buffer. So we don't have to give up as quickly (and kill the thickpipe!) when there's congestion.</li>
<li>Add alternative versions of crypto.c and tortls.c to use libnss or libgcrypt+gnutls.</li>

Translation Examples: <a
href="http://membres.lycos.fr/geolemalin/anonymat_garantit.htm">French</a>,
<a href="http://tor.freesuperhost.com/">Persian</a>, and <a
href="http://www.gamevn.com/forum/showthread.php?t=103346">Vietnamese</a>.)</li>
<li>If you know a question that should go on <a
href="http://wiki.noreply.org/wiki/TheOnionRouter/TorFAQ">the FAQ Wiki</a>, please
add it and answer it.</li>
<li>Document how to do exit node caching: tie into squid or other caching
web proxy.</li>
<li>Take a look at <a
href="http://wiki.noreply.org/wiki/TheOnionRouter/SquidProxy">Martin's
Squid and Tor page</a>, and update it to reflect Tor's <a
href="http://tor.eff.org/tor-manual.html">RedirectExit</a> config option. </li>
<li>Improve and clarify the wiki entry on <a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ServerForFirewalledClients">port forwarding</a>.</li>
</ul>

<h2>Testing Challenges</h2>
<ul>
<li>Test out why some of our tor servers have dns resolvers that resolve
unknown addresses to 127.0.0.1.

<ul>
<li>Identify the servers that experience this issue. </li>
<li>Identify how to cause and repair the issue in BIND, DJBDNS, or
whatever daemon the misconfigured servers use.</li>
</ul></li>

<li>Figure out how to setup web proxy gateways to let normal people
browse hidden services.  (This has been done a few times, but nobody has
sent us code.)</li>

<h2>Research Challenges</h2>
<ul>
<li>Arranging membership management for independence.

<ul>
<li>Sybil defenses without having a human bottleneck.</li>
<li>How to gather random sample of nodes.</li>
<li>How to handle nodelist recommendations.</li>
<li>Consider incremental switches: a p2p tor with only 50 users has
different anonymity properties than one with 10k users, and should be
treated differently.</li>
</ul></li>

<li>Incentives to relay; incentives to exit.</li>
<li>Allowing dissidents to relay through Tor clients.</li>
<li>Experiment with mid-latency systems. How do they impact usability,
    how do they impact safety?</li>
<li>Understand how powerful fingerprinting attacks are, and experiment
    with ways to foil them (long-range padding?).</li>
<li>Attacking freenet-gnunet/timing-delay-randomness-arguments.</li>

<ul>
<li>Spec issue: if a resolve returns an IP4 and an IP6 address,
      which to use?</li>
<li>Add to exit policy code</li>
<li>Make tor_gethostbyname into tor_getaddrinfo</li>
<li>Make everything that uses uint32_t as an IP address change to use
      a generalize address struct.</li>
<li>Change relay cell types to accept new addresses.</li>
<li>Add flag to serverdescs to tell whether IPv6 is supported.</li>
</ul></li>

<li>make freecap (or whichever) do what we want.</li>
<li>scrubbing proxies for protocols other than http.</li>
<li>We need better default privoxy configs to ship.</li>
<li>We need a good scrubbing HTTP proxy; privoxy is unmaintained and
sucky.</li>
<li>A DNS proxy would let unmodified socks4/socks5 apps to work
well.</li>
<li>Add SOCKS support to more applications</li>
<li>store hidden service information to disk: dirservers forget service
descriptors when they restart; nodes offering hidden services forget
their chosen intro points when they restart.</li>
<li>Server CPU load is high because clients keep asking to make new
circuits, which uses public key crypto. Possible defenses include: using
helper nodes (fixed entry nodes); rate limiting the number of create
cells handled per second; having clients retry failed extensions a few
times; implementing ssl sessions; and using hardware crypto when
available.</li>
<li>We fear we might not work very well when servers have asymmetric
bandwidth. 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? We need somebody
who's good with networks to simulate this and help design
solutions.</li>
<li>Right now the hidden service descriptors are being stored on the
dirservers, but any reliable distributed storage system would do (for
example, a DHT that allows authenticated updates). Can somebody figure
out our best options and decide if they're good enough?</li>

</ul>

tor-webwml.git

revamp the volunteer page. put excess items at the end so we can remove them later.