Acceptable clock skew in tor 0.4.1
Hi, recently, tor has become more tolerant to skewed system clocks; great, thanks! At Tails, we would like to take advantage of these improvements in order to remove as much as we can of our not-quite-safe clock fixing code. Our testing suggests that: - A ±24h clock skew is now acceptable in most cases¹: tor bootstraps successfully. - While with a ±48h clock skew, tor fails to bootstrap. Could someone on the network team please confirm that these empirical results match what the code is currently supposed to do? Thanks in advance! [1] In some corner cases I see weird behavior (#32438). And obfs4proxy is stricter than that, which I should report on Trac. Cheers, -- intrigeri
intrigeri <intrigeri@boum.org> writes:
Hi,
recently, tor has become more tolerant to skewed system clocks; great, thanks!
At Tails, we would like to take advantage of these improvements in order to remove as much as we can of our not-quite-safe clock fixing code. Our testing suggests that:
- A ±24h clock skew is now acceptable in most cases¹: tor bootstraps successfully.
- While with a ±48h clock skew, tor fails to bootstrap.
Could someone on the network team please confirm that these empirical results match what the code is currently supposed to do?
Hello intri! I'm not really 100% up to date with the clock skew tolerance of Tor, but the ±24h value seems plausible since that's the range where tor considers a consensus to be "reasonably live" [0], which is what most of its subsystems require to work. An unfortunate exception here is v3 onion services: v3 onion services only tolerate skews of maximum ±3 hours [1] but in most cases even tighter than that. This is to assure that v3 clients and services have a recent and accurate view of the network. In theory all of Tor needs a recent and accurate view of the network, but v3 is particularly fragile because of the shared random value and the precise time periods. Sorry to break the bad news, but it is what it is. In theory we could potentially do improvements for v3 here, but this is not in the scope right now. Cheers! [0]: see networkstatus_consensus_reasonably_live() [1]: see networkstatus_get_live_consensus() which is used in the v3 system, and basically checks if the current time is between the consensus valid-after and valid-until.
[1] In some corner cases I see weird behavior (#32438). And obfs4proxy is stricter than that, which I should report on Trac.
Cheers, -- intrigeri _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
George Kadianakis:
An unfortunate exception here is v3 onion services: v3 onion services only tolerate skews of maximum ±3 hours [1] but in most cases even tighter than that. This is to assure that v3 clients and services have a recent and accurate view of the network. In theory all of Tor needs a recent and accurate view of the network, but v3 is particularly fragile because of the shared random value and the precise time periods.
Sorry to break the bad news, but it is what it is. In theory we could potentially do improvements for v3 here, but this is not in the scope right now.
Actually Tails should be fine: once Tor has bootstrapped Tails syncs the time using htpdate which should also fix v3 onion service access. So I believe intrigeri's questions were only for bootstrapping + creating a circuit to a non-onion end-point -- once Tails succeeds with those it *can* sync the time accurately. Cheers!
participants (3)
-
anonym -
George Kadianakis -
intrigeri