torproject/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-12-06 19:41:15 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

Fix revision counter bugs caused by bad SRV start time computation.

Browse Source 
Bug description: For each descriptor, its revision counter is the OPE
ciphertext of the number of seconds since the start time of its SRV value.
This bug caused us to confuse the SRV start time in the middle of the lifetime
of a descriptor in some edge-cases, which caused descriptor rejects.

Bug cause: The bug occurs when we fetch a 23:00 consensus after
midnight (e.g. at 00:08 when not all dirauths have fetched the latest 00:00
consensus). In that case, the voting schedule (which was used for SRV start
time calculation) would return a valid-after past-midnight, whereas our
consensus would be pre-midnight, and that would confuse the SRV start time
computation which is used by HS revision counters (because we would reset the
start time of SRV, without rotating descriptors).

Bug fix: We now use our local consensus time to calculate the SRV start time,
instead of the voting schedule. The voting schedule does not work as originally
envisioned in this case, because it was created for voting by dirauths and not
for scheduling stuff on clients.
This commit is contained in:
George Kadianakis
2018-08-17 15:10:20 +03:00
parent 075fcb599c
commit 5febea0d54
2 changed files with 51 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/test/test_shared_random.c
+34
View File
@@ -290,6 +290,40 @@ test_get_start_time_of_current_run(void *arg)
tt_str_op("2015-04-20 00:00:00", OP_EQ, tbuf);
}
{
/* We want the local time to be past midnight, but the current consensus to
* have valid-after 23:00 (e.g. this can happen if we fetch a new consensus
* at 00:08 before dircaches have a chance to get the midnight consensus).
*
* Basically, we want to cause a desynch between ns->valid_after (23:00)
* and the voting_schedule.interval_starts (01:00), to make sure that
* sr_state_get_start_time_of_current_protocol_run() handles it gracefully:
* It should actually follow the local consensus time and not the voting
* schedule (which is designed for authority voting purposes). */
retval = parse_rfc1123_time("Mon, 20 Apr 2015 00:00:00 UTC",
&mock_consensus.fresh_until);
tt_int_op(retval, OP_EQ, 0);
retval = parse_rfc1123_time("Mon, 19 Apr 2015 23:00:00 UTC",
&mock_consensus.valid_after);
retval = parse_rfc1123_time("Mon, 20 Apr 2015 00:08:00 UTC",
&current_time);
tt_int_op(retval, OP_EQ, 0);
update_approx_time(current_time);
voting_schedule_recalculate_timing(get_options(), current_time);
run_start_time = sr_state_get_start_time_of_current_protocol_run();
/* Compare it with the correct result */
format_iso_time(tbuf, run_start_time);
tt_str_op("2015-04-19 00:00:00", OP_EQ, tbuf);
/* Check that voting_schedule.interval_starts is at 01:00 (see above) */
time_t interval_starts = voting_schedule_get_next_valid_after_time();
format_iso_time(tbuf, interval_starts);
tt_str_op("2015-04-20 01:00:00", OP_EQ, tbuf);
}
/* Next test is testing it without a consensus to use the testing voting
* interval . */
UNMOCK(networkstatus_get_live_consensus);