tordate sometimes breaks obfs4 by messing with a correct clock
time_is_in_valid_tor_range returns false for clocks that are in the
last 30 minutes of the 3 hours Tor consensus validity range, and then
we’ll set the clock to the middle of the valid range. I’ve seen a case
when the clock that we set in such a case, in the hope it’ll help,
actually breaks obfs4 while it was otherwise very much looking like it
would have worked, had we not set a wrong system time: it had downloaded
a consensus successfully and could verify it. I don’t know if the
original system clock was correct or not: the user says it was correct
and in UTC but there might have been a misunderstanding. Anyhow, after
tordate changed the clock and restarted tor, obfs4proxy could not
connect anymore (apparently due to SSL problems that I can’t explain
except by clock mismatch).
I could not find why time_is_in_valid_tor_range() treats a clock,
that’s in the last 30 minutes of the 3 hours Tor consensus validity
range, as wrong and in need of fixing: we’ve had this code since the
very beginning of tordate
(58e1b1a3835dfa84c831ad2a4e205ae8c129494e, 2011! :) It could be
that back then, tor wasn’t good at refreshing its consensus before it
expired? In this case, for a clock set to 15:49:XY, I see “will expire
at 2018-06-14 16:00:00; fetching the next one at 2018-06-14 15:54:23” in
the logs.
In order to decrease the risk that we break stuff while trying to help, I think we should replace “30 minutes” with 5 or 10 minutes in this algorithm: it should still leave tor enough time to notice that its consensus is about to expire, and refresh it.
Feature Branch: bugfix/16972-tordate-dont-fix-correct-clock+force-all-tests
Related issues
- Related to #15548
Original created by @intrigeri on 16972 (Redmine)