[tor-bugs] #18816 [Core Tor/Tor]: We still wait 120 seconds for cert fetches from missing dir mirrors

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu May 5 01:32:34 UTC 2016


#18816: We still wait 120 seconds for cert fetches from missing dir mirrors
------------------------------------+------------------------------------
 Reporter:  arma                    |          Owner:
     Type:  defect                  |         Status:  needs_information
 Priority:  Medium                  |      Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor            |        Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal                  |     Resolution:
 Keywords:  must-fix-before-028-rc  |  Actual Points:
Parent ID:                          |         Points:  small
 Reviewer:  nickm                   |        Sponsor:
------------------------------------+------------------------------------
Changes (by teor):

 * status:  needs_review => needs_information


Comment:

 Replying to [comment:6 nickm]:
 > f2e9af1b859287d24201a65213ab6ad5362e9c99 --
 >   * looks fine, though the comment was a little unclear to me.  I'll fix
 that though.  '''nickm''' -- clarify the comment on
 download_status_cert_init to clarify that download_status_cert_init() is
 _not_ okay to call after the first failure has occurred.
 >
 > 87fdbb6 and bea0819 --
 >   * I'm not sure about these, because they bring back the presence of
 authorities as client enumerators.  With these patches, since every
 fallback will go down _sometimes_, every client will try an authority
 _sometimes_, and the authorities will still be able to enumerate them.
 What if, as an alternative solution, we just use a sdifferent schedule for
 certificate downloads?   Are they still really necessary with f2e9af1 ?

 I guess I worry about a situation where all the fallbacks are blocked, but
 the authorities are not. Then Tor 0.2.8 won't be able to bootstrap
 reliably, where 0.2.7 could. (I know this is rare.)

 And even if fallbacks don't go down, the authorities are still present in
 the list of fallbacks. With the current 100 fallbacks at weight 10 and 9
 authorities at weight 1, clients will try authorities 9 / 1009 ~= 1% of
 the time.

 That said, these certificate fetches only happen rarely - once on initial
 client bootstrap, and once each time a certificate expires. If a client
 has a valid consensus when a certificate expires, it fetches the
 certificates from a random directory in the consensus.

 So the overall chance of any client contacting an authority is:
 * 1% on initial bootstrap,
 * 1% each time its consensus stops being reasonably live (if tor isn't run
 for 72 hours)
 * on authority certificate expiry:
   * 1% if the consensus is not reasonably live
   * vanishingly small with a live consensus (the authorities I checked
 have consensus weight 20)

 We can do a few things to fix this:
 * don't fall back to an authority, always use fallbacks (revert 87fdbb6
 and bea0819)
 * fall back to a fallback first, then an authority (revert bea0819)
 * merge #18963 to re-use the same directory that gave us the consensus for
 certificates
 * weight the fallbacks higher (but equally) so the authorities see less
 than 1% of traffic

 I like a combination of:
 * fall back to an authority only after trying the fallback that gave you
 the consensus (#18963), and another fallback (merge #18963, revert
 bea0819)
 * decide how much traffic we want the authorities to get, and weight the
 fallbacks accordingly
  * one in a thousand would need a weight of 100
  * one in a million would need a weight of 100,000

 Thoughts?

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


More information about the tor-bugs mailing list