Year3

Phase 1 (February 28, 2013)

MUST DO

• 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 (moved)) [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 [ticket:6027 collected long-term fixed IPv6 addresses of directory authorities to be hard-coded] and [ticket:8374 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 [ticket:6752 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 (moved)) [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.

HOPE TO DO

• 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 (moved)) [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. An extended version of the technical report has been accepted for publication at FOCI '13.

• 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 (moved)) [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 [comment:16:ticket:7153 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 (closed)) [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 (moved)) [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 [#7883 (closed) 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)

MUST DO

• 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. [Karsten, Nick, Andrea, Steven, Rob, Roger]

The internal milestone for June 30 is a review of Steven's utp branch to decide whether it's a good basis for this deliverable.

The internal milestone for August 31 are simulation results of Steven's utp branch.

_ Status: in October, Karsten will complete the simulation in Shadow with Rob's help, and write a full final report with Stephen's help._

• 11. Combine traffic obfuscation (DPI-resistance) with address diversity of flash proxy. (#7167 (moved)) [David, George, Ximin, Nick, Andrea]

The ideal outcome consists of four parts: 1) A specification for generic composition of pluggable transports. Includes the notion of special transports (e.g. flash proxy) that can't just be redirected to another local port. Allows chaining/nesting of transports using unmodified pluggable transport programs (as long as they support the specification). A means of specifying a chain of transports in torrc, perhaps as special syntax for ClientTransportPlugin and ServerTransportPlugin lines. 2) Implementation of this specification for flashproxy(obfsproxy) on the client and websocket(obfsproxy) on the server. 3) pyptlib support for this composition. Documentation. 4) Integration of the implemented thing into a PTBB.

The intended outcome consists of these parts: 1) An informal design document similar to the specification above, but treated more as a prototype than a final design. Allows chaining of "typical" transports that actually connect where you tell them to (e.g. obfsproxy). Other transports (e.g. flash proxy) may have to be treated specially. 2) Implementation of the design document for flashproxy(obfsproxy) on the client and websocket(obfsproxy) on the server. The obfsproxy, flashproxy-client, and websocket-server programs used to do this composition are not necessarily exactly the same as their non-composed counterparts, but should share most of their code. 3) No special composition syntax in torrc; you make a wrapper program that encapsulates the composition, and call that from torrc. 4) Integration of the implemented thing into a PTBB.

The minimal outcome is a client program and a server program that do obfsproxy obfuscation on the data sent through a flash proxy connection. They may work by executing existing flashproxy-client and obfsproxy programs or by using their code, but the exact means isn't specified. The means of composing the programs isn't necessarily generic nor specified, or even nice enough to specify. But: you can do something equivalent to: ServerTransportPlugin obfs-flash exec ./obfs-flash-proxy-server and ClientTransportPlugin obfs-flash exec ./obfs-flash-proxy-client, and it will work.

The internal milestone for July 31 is to design and specify a way for Flashproxy traffic to be obfuscated using an obfuscating pluggable transport (like obfs2 or obfs3).

The internal milestone for September 30 is to have implemented obfuscation for Flashproxy as it was specified during the previous milestone of this deliverable.

'' Status: in October, George will integrate everything into a releasable PTBB, and write a full final report, both with Ximin and David's help.

• 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]

The internal milestone for August 31 is to get #4773 (moved) and #5040 (moved) merged into tor master.

Done: These improvements are merged. As newer Tor versions are released and adopted, we will get better metrics coverage.

• 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 (moved)) [Nick, Andrea, Roger, Rob, Ian]

_ Status: in October, Roger will write a report on the performance improvements that we have and have not implemented, and why, as long as a wishlist for future performance work, with Nick's help._

• 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 (moved)) [Nick/Andrea, Rob, Roger, Karsten]

_ Status: in October, Nick will implement an improved scheduler with Roger and Andrea's help, and -- if possible -- test it using Shadow and otherwise with Karsten's help. Nick will also write a full final report, probably with the same help.._

• 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 (moved)) [Sathya, Karsten, Roger]

_ Status: at-risk._

• 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 (moved)) [Nathan, Moritz, ??]

The expected outcome is a Gibberbot release that supports recording voice, sending it through the Tor network to another Gibberbot user, and playing it on the other side. Special focus of this work will be: a) mitigating any usability issues around high latency data transfer; b) do testing with popular XMPP services that work well with Tor (jabber.ccc.de, Dukgo) and XMPP server types recommended by Guardian Project (ejabberd); c) basic auditing of implementation via wireshark to prove it is working, and to understand traffic analysis implications (i.e. "does it look like I am sharing files?").

Internal milestones are a specification document and a design prototype by July 15, an alpha version by July 31, a beta version by August 31, and a release or release candidate by September 30.

HOPE TO DO

• 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 (moved)) [Matt, Colin]
• 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 (moved)) [Nick, Andrea, Roger, Linus]

The internal milestone for July 31 is to complete at least three out of the following four tasks: 1) a tor branch that makes TestingTorNetwork produce consensuses quicker (#8532 (moved)); 2) a Chutney branch that verifies that it can send and receive traffic (#8531 (moved)); 3) a tor branch that has a make target which bootstraps a local testing network and results in pass or fail (#8530 (moved)); 4) an improved FAQ entry explaining how to run a testing network (#8533 (moved)).

The internal milestone for October 31 is to complete at least three out of the following five Shadow improvements: 1) improve Tor's TestingTorNetwork option for simulations in Shadow; 2) add support for running bridges and a bridge authority (Shadow issue 113); 3) create a Debian package for Shadow (Shadow issue 111); 4) help Rob with adding support for running more than one Tor version in the same simulation (Shadow issue 114); 5) solve that 'Guard' flags are only assigned to first nodes started in a private Tor network (Shadow issue 146, #9206 (moved)).

_ Status: in October, Linus will complete (some of) these improvements, and write a full report._

• 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 (moved), #7174 (moved)) [Roger, Nick, Andrea]

The minimal outcome is to become convinced that no bug remains when we're using microdescriptors.

The ideal outcome is to add enough unit tests that we uncover and fix the bug when UseMicrodescriptors is 0, where fixing the bug might require design changes. If fixing the bug turns out to be too hard, an intermediate option might be to confirm that an assert remains, and teach tor to recognize when you've configured a bridge that also showed up in the consensus, and then warn and fail in some way, preemptively, before it asserts.

Done: The minimum outcome is complete, and the ideal outcome is not forthcoming.

• 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]

Stalled: we cannot proceed without open code.

• 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]

Stalled: we cannot proceed without open code.

• 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 (moved)) [Rob, Roger, Karsten]
• 23. Patch the Tor Browser Bundle so it starts using Tor's "optimistic data" feature. (#3875 (moved)) [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

[[TicketQuery(keywords~=SponsorF2013,type=project,status=!closed,format=table,col=id|summary|keywords|owner|component)]]

Closed project tickets

[[TicketQuery(keywords~=SponsorF2013,type=project,status=closed,format=table,col=id|summary|keywords|owner|component)]]