Year2 · Wiki · Legacy / Trac

Phase 1 (March 15, 2012)

MUST DO

1. tor: reduce token bucket refill interval, which could greatly improve performance in some situations since we'll smooth out the TCP performance between relays. (#4465 (moved)) [Roger, working with Rob and Kevin] Done: in Tor 0.2.3.5-alpha we added the code to refill token buckets at a set interval, and picked "every 100ms" as a good balance (#3630 (moved)). We compared performance in simulated networks, confirming our guess about an appropriate value and also showing that it should be helping performance (#4086 (moved)).
1. tor performance: Build and execute a plan for proposal 182 from Florian and Björn, to change Tor's incoming and outgoing rate limiting to play better with TCP. We should figure out how it does or does not relate to the n23 congestion control design, to Ian's ideas about Defenestrator, etc. (#4682 (moved)) [Roger, working with Rob and Kevin] Partly done: the good news is that this design operates at a different level from n23 (connection rate limiting vs circuit flow control). See the table of prioritized performance designs for details. Simulation results (#5336 (moved)) show that the patch isn't broken and ought to provide a slight performance improvement. Follow-up plans are to revise the current patch (#4712 (moved)).
1. research: next steps after the datagram-transport comparison document. We have a variety of proposals on the table, and it's not clear which of them are good. Our secret weapon now is that there are two full-Tor-network simulators out there. For the interim deliverable, we should come up with a testing plan, pick one or more of the datagram-based designs, and design a testing setup (probably involving the simulators). (#4683 (moved)) [Steven, working with Rob and/or Kevin] Done: We have written up a testing plan. In summary, we have developed a set of tasks and provisionally assigned people to do them. We also have priorities for testing different approaches. We'll start with libutp doing hop-by-hop reliability.
1. tor: further extensions as needed from the Tor perspective for pluggable transport (proposal 180) support. (#4685 (moved)) [Nick and George] Done: We identified three extensions to Tor for pluggable transports: advertise pluggable transports in extra-info descriptors (#3589 (moved)); add support for SOCKS parameters in Bridge and {Client,Server}TransportPlugin torrc lines (#3594 (moved)); implement extended OR port (#4773 (moved)). We have reviewed code for the these three tickets. Once there's an 0.2.4 branch, we'll review these patches again and merge them. During the process of updating these designs to produce the new proposal 196, we identified other areas necessary for better pluggable transport integration.
1. tor: Make and maybe blog about a plan for proposal 179 integration and the censorship arms race. Proposal 179 is the "here are hundreds of ways to change our SSL certs to not stand out as much compared to normal SSL certs" proposal. How much should we fix preemptively, and when? (#4958 (moved)) [Jake, Nick] Done: We wrote proposal 195 which discusses TLS certificate normalization for Tor 0.2.4.x. We have also finalized plans plans for normalizing our declared cipher lists (#4744 (moved)), and renegotiation identifier position (#5390 (moved)).
1. pluggable transports: help SponsorF design a roadmap for the scope of transports we expect need work; what security properties each of them aims to provide (i.e. what censorship techniques it aims to defeat); figure out how far along we are at each of them and what research and development roadblocks remain; prioritize them by complexity and urgency of deployment; and build a plan for how to compose them appropriately without screwing up their properties. For each item, speculate a bit about how easy and/or smart it would be to bake into Tor itself. (#4679 (moved)) [Steven, George, Nick, others] Done: Of the currently available pluggable transports, obfs2 is a good default due to its efficiency and resistance to blocking. StegoTorus offers alternative pluggable transports which are significantly harder to block, but come with a much higher overhead. Suggestions for future development are listed in this report.

SHOULD DO

1. pluggable transports: Come up with a recommended approach for an external program that discovers bridge addresses to tell Tor about them. Does it tell Vidalia, which setconfs them? Should it be a Vidalia plugin, or launched by Vidalia? Or can we integrate it into Torbutton? Or should it be a separate program and talk the controller protocol itself? Should we extend the stdin/stdout PT protocol? Or should the separate program just be an independent proxy, and never even tell Tor about the bridges? I am thinking in particular of the ISC program that will take in an n-tuple from a rendezvous service and output some bridge addresses, but it would be good to have a plan for future similar tools. Write proposals and start implementation as needed. (#5010 (moved)) [Nick, George, Tomas, Mike, Roger, everybody]. Done: We have a design sketch in #5011 (moved) that has been reviewed and approved by everyone. We wrote a proposal that seeks to create a means for inter-controller communication using the Tor Control Port and another proposal that describes how the Tor client software can interact with an external program that performs bridge discovery.
1. pluggable transports: initial prototype of traffic morphing code, based on the UNC paper: http://freehaven.net/anonbib/#morphing09 Then integrate it with obfsproxy. Write a spec for the morpher (so everybody can know what exactly it does), and write a spec for a protocol that uses the morpher. Make contact with the "traffic morphing" research group at UNC, try to get them to review morpher, try to get them thinking about next steps, and learn what else they're up to. (#4680 (moved)) [George, Steven] Done: We implemented a packet-morphing prototype and wrote down our findings in a report. The report explains why we decided that traffic morphing, in its current technology state, is not the definite way to go.
1. research: feasibility analysis of simulating n23 with shadow and/or experimentor; feasibility analysis of simulating an n23 variant where alice's link to the entry relay is really slow (#4488 (moved)) [Roger, working with Rob and Kevin] Done: We fixed a variety of bugs in Shadow, Experimentor, and Tor (e.g. #5373 (moved)), and we located and cleaned up the original N23 patch from the Defenestrator authors (#4488 (moved)). Unfortunately, we uncovered a fundamental flaw in the current n23 design (#7346 (moved)). Next steps: design an n23 that can work (#7346 (moved)), write a spec for it (#5392 (moved)), and get some simulation results (#4486 (moved), #4487 (moved)). It's also likely that the "static n23" design is going to be inappropriate for real deployment, and nobody has yet invented an "adaptive n23" design that improves over static (#5379 (moved)).
1. bridges: Some sort of automated ground truth of bridge reachability from some countries. Without ground truth, none of our other "I wonder if this characteristic is a good way to measure whether the bridge is blocked" ideas can be tested. Needs a design that emphasizes minimization of scanning. (#5028 (closed)) [Runa, Arturo, George, Jake, Isis] Done: We developed a tool for scans of bridge lists which attempts to either open a simple TCP connection to the bridge's OR port or that will perform a full Tor handshake to the bridge. We tested the scanner by running a scan from .de and comparing results to bridge reachability information obtained from the bridge authority in .nl. We also performed a scan from .cn and found that over 80% of bridges were unreachable. We compared active scan results to passive usage statistics and confirmed that bridges that were found as unreachable in the scan also reported significantly fewer connections from .cn than other bridges. This work was done as part of #5028 (closed). We decided in July to further automate this process, and possibly revise it if a better methodology is proposed (#6414 (closed)).

Phase 2 (Nov 15, 2012)

MUST DO

1. obfsproxy: get a deployed package for both bridge and user side (#5551 (closed)) [Sebastian, George, Erinn] Done: We have client side bundles containing the 0.2.3.x release series and bridge side bundles for Windows containing the 0.2.4.x release series.
1. tor: Evaluate Ian Goldberg's theory that we can get rid of stream-level congestion windows in the protocol; and then either write a proposal and do it, or write an explanation of why they're still useful. (#4485 (moved)) [Nick, Steven, Roger, other?] Done: we wrote Tor Proposal 213, and discussion led to the conclusion that stream-level congestion windows are not redundant with circuit-level congestion windows. In fact, this difference uncovered a flaw with the current n23 design as well.
1. bridgedb: Deploy recaptcha support for https distribution strategy. Right now our bridgedb service is getting bombarded by automated bridge requests, which look an awful lot like an adversary trying to enumerate all the bridges. If we stick a manual captcha step in, we force them to move forward at the arms race. (#5481 (moved)) [Aaron] Done: BridgeDB now uses reCAPTCHA to slow datamining attempts. We negotiated with Google to permit proxying reCAPTCHA API requests on behalf of our users to protect their privacy, and then enabled BridgeDB's reCAPTCHA support on https://bridges.torproject.org/.
1. metrics analysis: what fraction of our bridges are not reporting usage statistics, and what do we think that implies about the accuracy of the usage statistics on our metrics page? (#3261 (moved)) [Karsten] Done: Wrote a report on what fraction of our bridges are not reporting usage statistics and a second report proposing an alternative approach for counting daily bridge users that is similar to how we estimate daily directly connecting users.
1. bridgedb: Annotate and sort the social-network bridge pools by stability and, once we have it, reachability. Right now we send a daily list of 50-100 bridges out, and half or more of the bridges are down the next day. We should track which bridges are up day after day and make them clearer in the list. (#5482 (moved)) [Aaron] Done: We have code in the development branch of BridgeDB that annotates bridges using stability information that is computed similar to how Tor directory authorities compute stability of relays and reachability information that is read from an external file.
1. research: Internet drafts for one or two TLS features to improve its traffic-analysis resistance. In particular, TLS needs better support for link padding, and for a mode where it does not send its record headers as plaintext. (Yes, TLS implementation moves bog-slow, but if we can get extensions in place, or something into TLS 1.x, we can do a lot of good here.) (#5488 (moved)) [Nick] Done: We have drafts for two specification notes/drafts: one is about padding; the other is about the StegoTorus "chopper" successor to obfsproxy thing. These drafts are not final versions, but preliminary drafts currently receiving feedback.
1. bridgedb: learn to take in a list of bridges blocked in a set of countries, and learn what country a user is asking for bridges in, and leave the blocked bridges out of the answer we provide. We'll want this building block once we have bridge reachability testing working. (#5484 (moved)) [Aaron] Done: BridgeDB's censorship descriptor format was extended to support bridges that have multiple or-addresses or listening ports. BridgeDB now learns about bridge censorship by parsing a list of blocked addresses and ports in censored regions. BridgeDB supports requests for bridge addresses "not blocked in" a region, and also supports region detection with GeoIP. BridgeDB responds from the set of bridges that are not blocked in the requested or (configurably) detected region.
1. tor: write a proposal for at what level of abstraction the "Tor does an SSL handshake with a real apache, posts a password over http to the server, and then gets passed to the real Tor relay" design should take place. Should the Tor client simply talk to a local proxy which does this dance, a la pluggable transports? Should Tor use a libevent2 filter? Something else? (#5548 (moved)) [Nick, others] Done: We wrote a proposal that discusses goals and designs for combining a bridge with a TLS-based service to deliver traffic to the bridge only if the client can demonstrate some shared knowledge.

SHOULD DO

1. pluggable transport: evaluate feasibility of a python equivalent to obfsproxy, to make it easier for people to write transports in python. See also Brandon Wiley's "dust". If we decide it's smart, get it started. (#5549 (moved)) [Nick, George, Brandon] Done: We developed a Python library called pyptlib (docs) that makes it easier for people to write pluggable transports, and to turn already existing network obfuscation code to pluggable transports (#5614 (moved)). We also wrote a Python port of obfsproxy -- called 'pyobfsproxy' for now -- that uses pyptlib and implements the obfs2 pluggable transport. Even though it's still in a premature state, it's possible to use pyobfsproxy to speak the obfs2 protocol with a C-obfsproxy. We plan to continue developing pyobfsproxy in the future.
1. research: investigate nat piercing approaches for relays / bridges. (#4960 (moved)) [Jake, others?] Done: We wrote a tech report that discusses the current methods for enabling and enhancing Tor bridge and Tor relay reachability when behind a consumer grade NAT device. Such reachability improvements are extremely important for embedded devices that provide Tor relaying or Tor bridging services. We propose the use of NAT-PMP and/or UPnP protocol(s) to ensure that inbound connectivity is possible.
1. research: problem statement around "simulating tor networks by sampling random relays". An increasing set of research papers run their experiments using 20 Tor relays, sampled randomly by weight from the set of bandwidths in the operational Tor network. What sort of variance or inaccuracies should we expect? Now that there are large-scale Tor network simulators, we can actually try to answer these questions. (#4490 (moved)) [Roger, targeted toward Rob and Kevin] Done: We co-authored the paper "Methodically Modeling the Tor Network" that was published at CSET '12. That paper methodically models the Tor network by exploring and justifying every modeling choice required to produce accurate Tor experimentation environments. We find that our model enables experiments that characterize Tor's load and performance with reasonable accuracy.
1. research: next steps after the datagram-transport comparison document. First implementation and experiments from mid-March testing plan. Summarize results. (#4684 (moved)) [Steven] Partly done: We have a working implementation of Tor that maintains a TCP and uTP session in parallel and uses TCP for authentication then uTP for data transport. This should be good enough for performance measurement although its security is not adequate for real usage. The next step will be to compare its performance to an unmodified Tor using Shadow.
1. Some sort of transition work, e.g. working with Persian News Network to spread the word about Tor in Iran, then learn about and address usability issues from real users?
1. tor: Support for resolving destination names to IPv6 and exiting to IPv6 destinations (#5547 (moved)). [Linus, Nick and Andrea] Done: IPv6 exits are implemented and merged. We'll continue to refine the code over the course of the 0.2.4.x release series.
1. research: Write an updated version of the Tor Design paper to take into account all the changes to Tor since then. The idea would be to help researchers get started in understanding Tor, rather than have to read the source and a pile of research papers. (#5487 (moved)) [Steven and Nick] Done: We have three blog posts about the "Top changes in Tor since the 2004 paper" written and posted to the blog (1, 2, 3), and we have a draft of the revised Tor paper that contains all changes since 2004.

Project tickets

Open project tickets

Closed project tickets

Comments

Please register or sign in to add a comment.