4

What are the rules by which Tor Proxies select entry, exit, and middle nodes from the list of Tor nodes? Where is this implemented in the source code?

5

The rules for selecting nodes can be found in the path-spec. Specifically in §2.2 Path selection and constraints.

A few points from the section:

  • We do not choose the same router twice for the same path.
  • We do not choose any router in the same family as another in the same path. (Two routers are in the same family if each one lists the other in the "family" entries of its descriptor.)
  • We do not choose more than one router in a given /16 subnet (unless EnforceDistinctSubnets is 0).
  • We don't choose any non-running or non-valid router unless we have been configured to do so. By default, we are configured to allow non-valid routers in "middle" and "rendezvous" positions.
  • If we're using Guard nodes, the first node must be a Guard (see 5 below)

    For "fast" circuits, we only choose nodes with the Fast flag. For
    non-"fast" circuits, all nodes are eligible.

    For all circuits, we weight node selection according to router bandwidth.

    We also weight the bandwidth of Exit and Guard flagged nodes depending on the fraction of total bandwidth that they make up and depending upon the position they are being selected for.

...

Additionally, we may be building circuits with one or more requests in mind. Each kind of request puts certain constraints on paths:

  • All service-side introduction circuits and all rendezvous paths should be Stable.
  • All connection requests for connections that we think will need to stay open a long time require Stable circuits. Currently, Tor decides this by examining the request's target port, and comparing it to a list of "long-lived" ports. (Default: 21, 22, 706, 1863, 5050, 5190, 5222, 5223, 6667, 6697, 8300.)
  • DNS resolves require an exit node whose exit policy is not equivalent to "reject :".
  • Reverse DNS resolves require a version of Tor with advertised eventdns support (available in Tor 0.1.2.1-alpha-dev and later).
  • All connection requests require an exit node whose exit policy supports their target address and port (if known), or which "might support it" (if the address isn't known). See 2.2.1.

2.2.1. Choosing an exit

If we know what IP address we want to connect to or resolve, we can trivially tell whether a given router will support it by simulating
its declared exit policy.

Because we often connect to addresses of the form hostname:port, we do not always know the target IP address when we select an exit node. In these cases, we need to pick an exit node that "might support" connections to a given address port with an unknown address. An exit node "might support" such a connection if any clause that accepts any connections to that port precedes all clauses (if any) that reject all connections to that port.

Unless requested to do so by the user, we never choose an exit node flagged as "BadExit" by more than half of the authorities who advertise themselves as listing bad exits.

  • Thanks! Should questions about actual implementation be apart of another question? What are guard nodes? – Kinnard Hockenhull Mar 6 '14 at 17:38
  • No, I think the implementation being here is fine, I just wasn't sure off the top of my head. Guard nodes are entry nodes (the first node in a Tor circuit). – Sam Whited Mar 6 '14 at 17:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.