wiki:org/sponsors/SponsorV

Timeline

October 2015 - September 2018 (...)

Overview

Joint project with Georgetown and NRL focusing on research about resilience to attacks that reduce anonymity or that deny service.

The grant also includes a "transition to practice" component, which means we should not only help with the research side, but also build and deploy the more promising solutions.

Deliverables

  • Produce research papers
  • Release software (e.g. Tor) that includes fixes based on the research papers
  • Work with Micah Sherr and Rob Jansen

Denial of Service

We've added an entire DoS subsystem in tor in 0.3.3.x series. Main ticket is #24902 which will be backported very soon to 0.2.9, 0.3.1 and 0.3.2 stable version.

Ticket Summary Status Owner
#25202 Check the calculations in cc_stats_refill_bucket using non fatal assertions closed dgoulet
#24782 Set a lower default MaxMemInQueues value closed ahf
#25094 24902 fix breaks on clang closed
#25095 Update dir-spec.txt with recent consensus param additions closed dgoulet
#25122 geoip: Hook the client geoip cache into the OOM handler closed dgoulet
#25183 Implement a way to tell if an IP address is a known relay closed dgoulet
#25226 Circuit cell queue can fill up memory closed dgoulet
#25236 dos: Document torrc default values in the man page when not in the consensus closed dgoulet
#25248 DoS mitgation: improve documentation closed dgoulet
#25824 Integrate circuit max_cell_queue_size killer with DoS heartbeats closed dgoulet
#25223 dos: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failed closed dgoulet
#24767 All relays are constantly connecting to down relays and failing over and over closed dgoulet
#24902 Denial of Service mitigation subsystem closed dgoulet
#25128 Bug: src/or/dos.c:312: cc_stats_refill_bucket: Non-fatal assertion new_circuit_bucket_count >= stats->circuit_bucket failed closed dgoulet
#25193 dos: Avoid blacklisting Exit relays closed dgoulet

Guard

Tentative Roadmap

We currently believe that guard discovery attacks are the most serious threat to anonymity and availability of the Tor network. We are collecting tickets for the these vectors under the Trac keyword guard-discovery.

This roadmap is a living document. We do not have an exhaustive list of all attacks and fixes for guard discovery, and other attacks that are also in scope for this sponsor may appear at any time. No plan survives contact with the enemy.

Short Term (0.3.2/0.3.3)

Our short term plan is to go after low hanging fruit. Several of the guard discovery attack vectors are very easy to mitigate, but very hard to solve entirely. We must not let perfect be the enemy of good during this phase.

To start, a few relatively simple changes can be completed on the 0.3.2/0.3.3 timescale that should mitigate vectors relating to our statistics reporting and gathering:

Ticket Summary Owner Milestone
No tickets found

Ticket Summary Owner Milestone
No tickets found

Separate from the above, Proposal 247 is our proposal for changing Tor's path selection for hidden services to deal with middle-node trawling-based attacks. Unfortunately, Proposal 247 requires quite a bit of performance tuning before we can do a final implementation. The final implementation will also require extensive modifications to Tor's path selection code, at least for hidden services.

The good news is that we can provide significantly improved security before we complete a final implementation by providing torrc options and an add-on a Tor Controller that implements our intended path selection algorithm. This same add-on Tor controller will also be used for performance evaluation. The target release for this initial work is Tor 0.3.3, which freezes mid-January 2018. The set of development work for this is:

Ticket Summary Owner Milestone
#13837 Mitigate guard discovery by pinning middle node mikeperry Tor: 0.3.3.x-final
#23100 Circuit Build Timeout needs to count hidden service circuits mikeperry Tor: 0.3.3.x-final
#23101 Predict and build specific HS purpose circuits (rather than GENERAL) mikeperry Tor: 0.3.3.x-final
#23114 Circuit Build Timeout should apply at circuit completion mikeperry Tor: 0.3.3.x-final
#24487 Reverse path selection (choose outer hops first) mikeperry Tor: 0.3.4.x-final

Long Term (post-0.3.3)

After 0.3.3, we plan to simulate the performance properties of Prop247 using the add-on controller. Separately, we will also simulate the time-until-compromise estimates of various parameter choices. We will use the results of these experiments to finalize parameter choices for the native Tor implementation of Proposal 247.

Proposal 247 by itself is insufficient to deal with all forms of guard discovery. In particular, circuit lifetime attacks like #22728 suggest that we need some way of re-establishing circuits to an IP/RP over a new path. the conflux technique may be one way to do this. Note that for #22728 we do not need the flow control and load balancing pieces of conflux. We only need the ability to migrate an RP/IP from one path to another.

Here are all of the post-0.3.3 guard discovery tickets:

Ticket Summary Owner Milestone
#20212 Tor can be forced to open too many circuits by embedding .onion resources tbb-team Tor: unspecified
#22728 Long-lived onion service circuits can enable guard discovery Tor: unspecified
#22729 Revisit relay read/write history resolution (for onion services) Tor: unspecified
#23512 Bandwidth stats watermark can be induced using OOM killer Tor: unspecified
#23978 Write simulator to evaluate security of Prop247 parameter choices Tor: unspecified
#23979 Write performance simulator for Prop247 Tor: unspecified
#23980 Provide torrc option to kill hidden service circuits after $TIMEOUT, $NUM_BYTES, or guard changes. mikeperry Tor: unspecified
#24104 Delay descriptor bandwidth reporting on large relays Tor: unspecified
#25609 Investigate Tor client retry behavior on failing onions Tor: unspecified
#9001 Slow Guard Discovery of Hidden Services and Clients Tor: unspecified

Research Topics

As we address passive versions of #22728, we should also determine if the flow control mechanisms of conflux (or some other multipath routing) can provide any benefit against congestion attacks and other forms of denial of service attack against guard nodes.

XXX: I'm sure there are other things we need researched also.

Last modified 8 weeks ago Last modified on Feb 23, 2018, 6:47:52 PM