[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #18816 [Core Tor/Tor]: We still wait 120 seconds for cert fetches from missing dir mirrors
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs