Exit scanner should scan for Guard <-> Exit reachability

The Tor Exit Scanner should be checking to ensure that all Guard nodes can create circuits to all Exit nodes, to attempt to detect tagging and path bias attackers who fail circuits that don't go through colluding nodes.

added component::core tor/torflow owner::aagbsn parent::5456 priority::high resolution::wontfix status::closed type::defect labels

To keep this simple and sane, it should probably be a separate process that just performs the N^2 connection test in parallel to the main SoaT scan and then reports the results when its done. Both soat and this beast should be able to share the same Tor client.

Keeping it separate from both soat and the bw auths might also help keep it less discoverable. People could run it from anywhere.

aagbsn: I'm going to dump this one on you for now. We can talk about it more if you survive the ambush!^Wtrip.

Trac:
Owner: mikeperry to aagbsn
Status: new to assigned

In case anyone else is interested in this ticket, here's a paste of my reply to some questions about it on #tor-dev:

12:52 < mikeperry> meejah: There are examples of circuit creation in the torflow.git repository 12:53 < mikeperry> meejah: specifically https://gitweb.torproject.org/torflow.git/blob/HEAD:/CircuitAnalysis/BuildTimes/buildtimes.py 12:58 < mikeperry> meejah: the way the exit scanners work right now is that the main scanner soat.py keeps scanning over the network and generating .result files. These result files are then picked up by snakeinspector.py which is run from a cron job 12:58 < mikeperry> and snakeinspector.py mails particularly bad results to a mailinglist 12:58 < mikeperry> this code lives in https://gitweb.torproject.org/torflow.git/tree/HEAD:/NetworkScanners/ExitAuthority 12:59 < mikeperry> you don't have to integrate with that code, but I would recommend using the path support routines used by buildtimes.py

I'm interested in writing a GSoC proposal for this ticket. I have two general questions:

1. Are we going to write a new test class in soap.py for this? Does it need a whole summer to complete?
2. I don't know much about "tagging and path bias attackers" and how this test should work. How should I figure it out? Thanks.

Trac:
Username: reganeet

Replying to reganeet:

2. I don't know much about "tagging and path bias attackers" and how this test should work. How should I figure it out?

http://freehaven.net/anonbib/#ccs07-doa is the original paper on the topic.

The very short version of the issue is that an adversary who runs some relays can try to fail circuits that a) use one or more of his relays but b) he can't do traffic analysis on because his relays aren't in the right positions in the circuit to win. That will cause the user to make a new circuit, giving the attacker more chances at winning.

Somewhat related to this, there is a tool to measure Guard failure rates in a txtorcon branch here: https://github.com/meejah/txtorcon/blob/exit_scanner/apps/exit_scanner/failure-rate-scanner.py

(That is, it chooses a bunch of Guard nodes and asks Tor to set up circuits using them, so can't directly be used for Guard cross Exit scanning but still could be useful?)

Trac:
Cc: aagbsn to aagbsn, meejah@meejah.ca

A low-cost network reliability scanning technique is described in http://arxiv.org/abs/1110.5395. However, the number of circuits required is still on the order of H * N * l, where H=3 is the number of hops, N=3000 is the number of nodes, and l=10 is the number of probes per node. This is still like 90,000 circuits if you scan every node. We could potentially only scan high-capacity nodes though, I guess.

ExitAuthority is not maintained anymore

Trac:
Status: assigned to closed
Sponsor: N/A to N/A
Reviewer: N/A to N/A
Resolution: N/A to wontfix

closed

mentioned in issue #6135 (moved)

mentioned in issue tpo/core/tor#6135 (closed)

moved to tpo/network-health/torflow#5459 (closed)