Version 37 (modified by karsten, 7 years ago) (diff)

Call Mike's item 23 done.

Phase 1 (February 28, 2013)


  • 1. Nick helps Vinod track Vinod's libevent/Stegotorus bug. [Nick]

The expected outcome of this deliverable is to make significant progress in characterizing the bug, ideally to either say that the bug is in libevent and fix it, or to say that there's no such bug in libevent and to fix the bug in StegoTorus. If a complete diagnosis or fix requires a lot more work than expected, it may be delivered at a later date in year 3.

Done: We tracked this down to a bug in StegoTorus that caused connections to get closed too early if libevent's read sizes were smaller than StegoTorus expected.

  • 2. Let directory authorities advertise IPv6 addresses, so IPv6 clients can bootstrap directly into the Tor network without needing a bridge. (#6027) [Nick]

The expected output of this deliverable is a Tor branch that includes a set of initial directory caches with IPv6 addresses for use by clients which cannot talk to IPv4 relays, and code so that these clients correctly restrict their direct connections to nodes with IPv6 addresses once they find out they cannot bootstrap via IPv4.

Done: We wrote a branch to be reviewed and merged into 0.2.5.x that allows users to configure directory authorities and fallback directory servers with IPv6 addresses and ORPorts. We collected long-term fixed IPv6 addresses of directory authorities to be hard-coded and wrote a tool to compile a list of long-term fixed IPv6 addresses of directory mirrors from descriptor archives to be shipped with bundles.

  • 3. Continue working with the Shadow and ExperimenTor developers to help them improve their ability to accurately simulate Tor networks. And do that for the Deterlab folks too. [Roger, Karsten]

The expected outcome of this deliverable is: 1) some easy fixes to make the TestingTorNetwork config option more reliable; 2) a Tor branch that allows exporting much more detailed usage information to a relay's control port, plus a patch to control-spec.txt.

Done: We proposed new controller events to better understand connection/circuit usage and worked on an implementation to be reviewed and merged into Tor 0.2.5.x. We identified and fixed bootstrapping issues in testing networks from too high directory fetch retry schedules in a branch to be reviewed and merged into 0.2.5.x.

  • 4. Continue working with external researchers (including other groups getting funding, like the NRL group) so their Tor results are more likely to be useful in practice. For example, Aaron Johnson is working on network diversity metrics. Making sure we have enough "support developers" like Sathya will mean our data/scripts are easier for people like Aaron to use. [Roger, Sathya, Karsten]

The expected outcomes of this deliverable are code reviews and programming support for a Tor path simulator.

Done: We discussed path selection algorithms with Aaron Johnson and wrote an extensible Tor path simulator that we plan to maintain and provide to other researchers.

  • 5. Evaluate, possibly revise, and implement proposal 195 (TLS certificate normalization). (#7145) [Nick, Andrea, Jake, ??]

The expected deliverable is a Tor branch containing some anti-censorship features related to certificate and ciphersuite list flexibility, containing those ideas from and related to proposal 195 with the highest cost-benefit ratio.

Done: We wrote a branch that allows clients to override the default cipher list and bridge operators to specify their own link certificates.


  • 6. Start a tool that a censored developer can run to discover why their Tor is failing to connect: brainstorm a list of "things to check", and sort them by how useful they'd be to check / how hard they'd be to build. (#7137) [Philipp, Runa, many]

The expected outcome of this deliverable is a blog post or technical report sketching out the requirements and the technical feasibility of a user-friendly Tor censorship analyzer based on OONI.

Done: Final results from this deliverable are a technical report which discusses design requirements for a censorship analysis tool and a blog post referencing this technical report.

  • 7. Either support the pluggable transport interface that StegoTorus expected us to have (i.e. no longer require transports to be socks proxies), or write up a recommendation for how to interface with Tor correctly if you're in StegoTorus's situation. (#7153) [Nick, Andrea, George; we'll need Zack to explain the current rationale]

The expected outcome of this deliverable is to figure out what the right answer for StegoTorus is and write it up, and if possible and time permits, implement any required Tor changes in a Tor branch.

Deferred: We wrote a proposed set of solutions that is pending feedback. We'll need to turn this into a proposal and a set of tickets.

  • 8. Make Torperf results more realistic -- real web pages average 320KB and contain multiple components. We can track the performance we see fetching a given artificial web page over time, and/or the performance of the Facebook page as it and Tor both change over time. (#7168) [Karsten, Ian, ??]

The expected outcome of this deliverable is a Torperf branch that fetches arbitrary web pages over Tor using a local Firefox browser, a metrics-db branch that collects the new performance data, and a metrics-web branch that aggregates and visualizes request times.

Deferred: We wrote a simple prototype that measures performance using Selenium/Firefox, and we discussed and implemented a working prototype of a Twisted-based Torperf. Combining the two efforts is going to happen early in phase 2.

  • 9. Make further progress on the pyobfsproxy framework, including getting it in use by some actual user somewhere to make sure it's going in the direction we want. (#5614) [George]

The expected outcome of this deliverable is: 1) a working set of instructions for running a pyobfsproxy bridge on Debian; 2) a trial TBB for Windows with pyobfsproxy rather than obfsproxy; 3) research and potentially implement the use of pyptlib in flashproxy; 4) a scriptable integration test suite for pyobfsproxy.

Done: We proceeded with the development and deployment of pyobfspoxy: we improved the installation instructions; we created a trial TBB for Windows containing flashproxy and pyobfsproxy; we discussed pyptlib integration in flashproxy with David Fifield and wrote a flashproxy patch to support pyptlib; and we wrote a prototype of PITS, the Pyobfsproxy Integration Test Suite.

Phase 2 (October 31, 2013)


  • 10. UDP (or other smart transport) as underlying node-to-node transport: have a Tor branch that, when run as a separate Tor network, layers an in-order reliable transmission protocol over UDP packets (or other smart transport) on the wire (ideally with some link encryption like ipsec over that). Be thinking about transition / deployability. [Nick, Andrea, ??]

The expected outcome for March 31 is a review of Steven's utp branch to decide whether it's a good basis for this deliverable.

  • 11. Combine traffic obfuscation (DPI-resistance) with address diversity of flash proxy. (#7167) [David, George, Nick, Andrea, ??]
  • 12. Determine how to safely record and report user statistics for obfsproxy bridges. Then get some statistics up on the user metrics page. [Nick/Andrea, George, Karsten]
  • 13. Write a proposal for N23, and write a patch for N23 that functions correctly. Then simulate it to see how it performs for typical and for really slow client connections. (#4506) [Nick, Andrea, Roger, Rob, Ian]
  • 14. Evaluate alternate scheduling algorithms for choosing which relay to push bytes to (and/or read from) next. Right now we choose fairly between all relays, and maybe choosing weighted by bandwidth (or by which connection recently gave us a cell for a high-priority circuit) is better. (#4585) [Nick/Andrea, Rob, Roger, Karsten]
  • 15. Investigate raising the minimum bandwidth for getting the Fast flag. This involves looking at diversity implications (since we'll have fewer relays), and also at performance implications (since we'll have fewer slow relays, but less capacity). (#1854) [Sathya, Karsten, Roger]
  • 16. VoIP support: make a proof-of-concept push-to-talk VoIP variant for Android that tolerates high latency because users use it differently (e.g. "record an mp3, send it through the network, play it on the other side"). (#5700) [Nathan, Moritz, ??]


  • 17. VoIP support: pick an existing VoIP client (like mumble), and write instructions for using it over TCP, even though it will be high latency and high variance. (#5699) [Nathan, Moritz, ??]
  • 18. Improve configuration options and instructions for running private Tor networks in testing and simulation environments. Making TestingTorNetwork smoother and more reliable will be useful for Shadow (Rob keeps running into bugs where his testbed network behaves funny due to TestingTorNetwork), and it would also be useful for the Deterlab folks (who also ran into bugs with their internal Tor deployment). Maybe that's best done by improving Chutney so we can notice problems, or maybe it's best done by embracing Shadow. (#7172) [Nick, Andrea, Roger, Linus]
  • 19. Let users configure a public relay to be their bridge without crashing, since an increasing number of demo scenarios involve picking a public relay as your bridge. (#1776, #7174) [Nick, Andrea]
  • 20. Prototype integration of Defiance's client-side components (qtapp, acs-dancer) into the Tor Browser Bundle, starting with implementing the necessary components of proposal 199 -- unless the modfreedom code is so unlike the expected API that we instead need to recommend changes to how modfreedom wants to interface to Tor. Note: we'll only look at open-source published tools/documents, so while these components aren't open, we won't be making progress here. Nick, Andrea, Mike, Erinn
  • 21. Evaluate SponsorF's plans to stick a normal-looking apache (or better, nginx) server in front of the Defiance Tor component, and compare them to our proposal 203 ("Avoid censorship by impersonating an HTTPS server"). Make any necessary Tor-side changes, and make recommendations on what needs to change on the webserver side. Note: we'll only look at open-source published tools/documents, so while these components aren't open, we won't be making progress here. [Nick, Andrea, George, Roger]
  • 22. Evaluate classifiers for deciding which clients to throttle, and how much, a la Rob Jansen's Usenix Security 2012 paper. Implement a promising approach, simulate a network where everybody does it, and also try it on a real relay. (#5190) [Rob, Roger, Karsten]
  • 23. Patch the Tor Browser Bundle so it starts using Tor's "optimistic data" feature. (#3875) [Mike, Tau]

Done: We patched TBB to use Tor's optimistic data feature and deployed this change in the stable bundle.

Project tickets

Open project tickets

Ticket Summary Keywords Owner Component
#7153 Don't require pluggable transport proxies to be SOCKS proxies SponsorF20130228, needs-spec-change, needs-tor-change Circumvention/Pluggable transport

Closed project tickets

Ticket Summary Keywords Owner Component
#3875 TBB's Firefox should use optimistic data socks handshake variant tbb-performance roundtrip MikePerry201304 tbb-bounty SponsorF20131101 tbb-no-uplift mikeperry Applications/Tor Browser
#6027 Directory authorities on IPv6 ipv6, tor-auth, SponsorF20130315, 026-triaged-1, 026-deferrable, nickm-patch, 027-triaged-1-out, pre028-patch Core Tor/Tor
#7137 Build a tool that a censored developer can run to discover why their Tor is failing to connect SponsorF20130228 Circumvention/Censorship analysis
#7145 Evaluate, possibly revise, and then implement ideas for TLS certificate normalization SponsorF20130228 tor-client nickm Core Tor/Tor
#7167 Combine traffic obfuscation with address diversity of flash proxy SponsorF20131101 flashproxy fog asn Circumvention/Pluggable transport