tor-webwml.git

@@ -1556,216 +1556,6 @@ implementation.

     </li>

     </ol>

-

-    <a id="OtherCoding"></a>

-    <h2><a class="anchor" href="#OtherCoding">Other Coding and Design related ideas</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="<wiki>doc/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://svn.torproject.org/svn/libevent-urz/trunk/">good

-    start</a> on this in the summer of 2007.</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 — 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. It has been lightly tested and is

-    possibly very buggy.  We're looking for more rigorous testing,

-    performance analysis, and optimally, code fixes to OpenSSL and

-    Tor if needed.</li>

-

-    <li>Write a <a

-    href="https://secure.wikimedia.org/wikipedia/en/wiki/Fuzz_testing">fuzzer</a>

-    for Tor to discover security vulnerabilities. Determine if there

-    are good fuzzing frameworks 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="<page docs/faq>#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="<specblob>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>

-

-    <li>We need a way to generate the website diagrams (for example, the "How

-    Tor Works" pictures on the <a href="<page about/overview>">overview page</a>

-    from source, so we can translate them as UTF-8 text rather than edit

-    them by hand with Gimp. We might want to

-    integrate this as an wml file so translations are easy and images are

-    generated in multiple languages whenever we build the website.</li>

-

-    <li>How can we make the various LiveCD/USB systems easier

-    to maintain, improve, and document?  One example is <a

-    href="https://tails.boum.org/">The Amnesic Incognito Live

-    System</a>.

-    </li>

-

-    <li>

-    Another anti-censorship project is to try to make Tor

-    more scanning-resistant.  Right now, an adversary can identify <a

-    href="<specblob>proposals/125-bridges.txt">Tor bridges</a>

-    just by trying to connect to them, following the Tor protocol,

-    and seeing if they respond.  To solve this, bridges could <a

-    href="<svnprojects>design-paper/blocking.html#tth_sEc9.3">act like

-    webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools,

-    and not act like bridges until the user provides a bridge-specific key.

-    To start, check out Shane Pope's <a

-    href="http://dl.dropbox.com/u/37735/index.html">thesis and prototype</a>.

-    </li>

-

-    </ol>

-

-    <a id="Research"></a>

-    <h2><a class="anchor" href="#Research">Research</a></h2>

-    <ol>

-    <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>A related question is: Does running a relay/bridge provide additional

-    protection against these timing attacks? Can an external adversary that can't

-    see inside TLS links still recognize individual streams reliably?

-    Does the amount of traffic carried degrade this ability any? What if the

-    client-relay deliberately delayed upstream relayed traffic to create a queue

-    that could be used to mimic timings of client downstream traffic to make it

-    look like it was also relayed? This same queue could also be used for masking

-    timings in client upstream traffic with the techniques from <a

-    href="http://www.freehaven.net/anonbib/#ShWa-Timing06">adaptive padding</a>,

-    but without the need for additional traffic. Would such an interleaving of

-    client upstream traffic obscure timings for external adversaries? Would the

-    strategies need to be adjusted for asymmetric links? For example, on

-    asymmetric links, is it actually possible to differentiate client traffic from

-    natural bursts due to their asymmetric capacity? Or is it easier than

-    symmetric links for some other reason?</li>

-    <li>Repeat Murdoch and Danezis's <a

-    href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta">attack from

-    Oakland 05</a> on the current Tor network. See if you can learn why it

-    works well on some nodes and not well on others. (My theory is that the

-    fast nodes with spare capacity resist the attack better.) If that's true,

-    then experiment with the RelayBandwidthRate and RelayBandwidthBurst

-    options to run a relay that is used as a client while relaying the

-    attacker's traffic: as we crank down the RelayBandwidthRate, does the

-    attack get harder? What's the right ratio of RelayBandwidthRate to

-    actually capacity? Or is it a ratio at all? While we're at it, does a

-    much larger set of candidate relays increase the false positive rate

-    or other complexity for the attack? (The Tor network is now almost two

-    orders of magnitude larger than it was when they wrote their paper.) Be

-    sure to read <a href="http://freehaven.net/anonbib/#clog-the-queue">Don't

-    Clog the Queue</a> too.</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/index.php/hpn-ssh/638">ssh

-    throughput experiment</a>. We'll need to measure and tweak, and maybe

-    overhaul if the results are good.</li>

-    <li>Our censorship-resistance goals include preventing

-    an attacker who's looking at Tor traffic on the wire from <a

-    href="<svnprojects>design-paper/blocking.html#sec:network-fingerprint">distinguishing

-    it from normal SSL traffic</a>. Obviously we can't achieve perfect

-    steganography and still remain usable, but for a first step we'd like to

-    block any attacks that can win by observing only a few packets. One of

-    the remaining attacks we haven't examined much is that Tor cells are 512

-    bytes, so the traffic on the wire may well be a multiple of 512 bytes.

-    How much does the batching and overhead in TLS records blur this on the

-    wire? Do different buffer flushing strategies in Tor affect this? Could

-    a bit of padding help a lot, or is this an attack we must accept?</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>

-    <li>Programs like <a

-    href="<page docs/torbutton/index>">Torbutton</a> aim to hide

-    your browser's UserAgent string by replacing it with a uniform answer for

-    every Tor user. That way the attacker can't splinter Tor's anonymity set

-    by looking at that header. It tries to pick a string that is commonly used

-    by non-Tor users too, so it doesn't stand out. Question one: how badly

-    do we hurt ourselves by periodically updating the version of Firefox

-    that Torbutton claims to be? If we update it too often, we splinter the

-    anonymity sets ourselves. If we don't update it often enough, then all the

-    Tor users stand out because they claim to be running a quite old version

-    of Firefox. The answer here probably depends on the Firefox versions seen

-    in the wild. Question two: periodically people ask us to cycle through N

-    UserAgent strings rather than stick with one. Does this approach help,

-    hurt, or not matter? Consider: cookies and recognizing Torbutton users

-    by their rotating UserAgents; malicious websites who only attack certain

-    browsers; and whether the answers to question one impact this answer.

-    </li>

-    <li>How many bridge relays do you need to know to maintain

-    reachability? We should measure the churn in our bridges. If there is

-    lots of churn, are there ways to keep bridge users more likely to stay

-    connected?

-    </li>

-    </ol>

-

-    <p>

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

-    of these!

-    </p>

   </div>

   <!-- END MAINCOL -->

   <div id = "sidecol">