Opened 8 years ago

Closed 3 years ago

#5459 closed defect (wontfix)

Exit scanner should scan for Guard <-> Exit reachability

Reported by: mikeperry Owned by: aagbsn
Priority: High Milestone:
Component: Core Tor/Torflow Version:
Severity: Keywords:
Cc: aagbsn, meejah@… Actual Points:
Parent ID: #5456 Points:
Reviewer: Sponsor:


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.

Child Tickets

Change History (8)

comment:1 Changed 8 years ago by mikeperry

To keep this simple and sane, it should probably be a separate process that just performs the N2 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.

comment:2 Changed 8 years ago by mikeperry

Owner: changed from mikeperry to aagbsn
Status: newassigned

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

comment:3 Changed 8 years ago by mikeperry

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
12:58 < mikeperry> meejah: the way the exit scanners work right now is that the main scanner keeps scanning over the network and generating .result files. These result files are then picked up by which is run from a cron job
12:58 < mikeperry> and mails particularly bad results to a mailinglist
12:58 < mikeperry> this code lives in
12:59 < mikeperry> you don't have to integrate with that code, but I would recommend using the path support routines used by

comment:4 Changed 8 years ago by reganeet

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 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?


comment:5 in reply to:  4 Changed 8 years ago by arma

Replying to reganeet:

  1. I don't know much about "tagging and path bias attackers" and how this test should work. How should I figure it out? 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.

comment:6 Changed 8 years ago by meejah

Cc: meejah@… added

Somewhat related to this, there is a tool to measure Guard failure rates in a txtorcon branch here:

(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?)

comment:7 Changed 8 years ago by mikeperry

A low-cost network reliability scanning technique is described in 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.

comment:8 Changed 3 years ago by tom

Resolution: wontfix
Status: assignedclosed

ExitAuthority is not maintained anymore

Note: See TracTickets for help on using tickets.