[tor-bugs] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough directory
information
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:  asn
     Type:  defect                               |         Status:
                                                 |  assigned
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.3.x-final
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  0.3.0.6
 Severity:  Normal                               |     Resolution:
 Keywords:  031-backport, 032-backport,          |  Actual Points:
  033-must, tor-guard, tor-client, tbb-          |
  usability-website, tbb-needs,                  |
  033-triage-20180320, 033-included-20180320     |
Parent ID:  #21969                               |         Points:  1
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by mikeperry):

 Replying to [comment:13 nickm]:
 > You don't even need the flag -- you can check how many open hops the
 circuit has.  If it has >= 1, then it has extended at least one hop, and
 the DESTROY cell might not be from the guard.  If it has 0 open hops, then
 it hasn't extended to the guard yet.

 To clarify, the function (or check) you want to use is
 circuit_get_cpath_opened_len(), not circuit_get_cpath_len(). (This is also
 what dgoulet said in terms of the check, but I wanted to make sure the
 right function is used).

 Wrt why there were no path bias messages -- the path bias code only counts
 circuits that made it to the third hop. This is because it is only
 checking for circuits that fail during tagging, which would allow them to
 survive to the 2nd hop but fail at the 3rd (due to our current lack of any
 MAC mechanism at hop 2). So the lack of those messages is also consistent
 with the guard failing with RESOURCELIMIT from itself.

 Given that, I think it is reasonable to give up on the guard temporarily
 and treat it as if the TLS connection failed: switch to the second guard
 for now, with the hopes of the prop271 code going back to it eventually.

 Yet another case where the adversary or just bad luck can force you to use
 a second guard, but I don't see a way around that. Sitting around waiting
 and doing nothing is arguably even worse, and leaks even more info
 (because for eg, the targeted HS would go down).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25347#comment:14>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online