Opened 2 years ago

Closed 22 months ago

Last modified 16 months ago

#26931 closed defect (not a bug)

Wrong service-side HSv3 hash ring for HSv3 once a day (low impact)

Reported by: asn Owned by:
Priority: Medium Milestone: Tor: 0.3.5.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs hsv3 reachability
Cc: dgoulet Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor27-can


Here is another bug we found with dgoulet at HOPE:

In set_rotation_time() we set the next rotation time to next midnight:

  service->state.next_rotation_time =
    sr_state_get_start_time_of_current_protocol_run() +

Supposedly we do that because at next midnight the next SRV value is computed, and hence we want the next descriptor to use that next SRV value.

However there is of course no guarantee that the service has the consensus with the right SRV at that point, and actually there is no chance that's the case since the consensus is computed exactly at midnight.

This means that the first upload of the next descriptor is done with a wrong HSDir. We think that this should not actually impact reachability since that first descriptor upload should only be used by severely clock skewed clients.

We should investigate more.

Child Tickets

Change History (4)

comment:1 Changed 22 months ago by dgoulet

Resolution: not a bug
Status: newclosed

After consideration, this is a no bug.

The reason is that we use the valid_after time of the consensus to rotate the descriptor so if the next_rotation_time is set to 00:00, then we won't rotate until we have a consensus that has its valid after time >= 00:00 meaning the consensus that has the new SRV.

See should_rotate_descriptors().

comment:2 Changed 17 months ago by pili

Sponsor: Sponsor27

comment:3 Changed 16 months ago by pili

Parent ID: #29995

comment:4 Changed 16 months ago by asn

Parent ID: #29995
Sponsor: Sponsor27Sponsor27-can
Note: See TracTickets for help on using tickets.