[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #26709 [Core Tor/Tor]: Onion V3 addresses not always working
#26709: Onion V3 addresses not always working
---------------------------+-----------------------------------
Reporter: time_attacker | Owner: (none)
Type: defect | Status: needs_information
Priority: Medium | Milestone:
Component: Core Tor/Tor | Version:
Severity: Critical | Resolution:
Keywords: onion, tor-hs | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
---------------------------+-----------------------------------
Comment (by dgoulet):
So I've been having this issue but rarely. This weekend, it happened to me
in the morning where one of my service wasn't computing the same hashring
as the client. No matter how many times I would restart the client, with
latest consensus, they were always different. So the service was the
issue.
Every single parameter on the service side was correct in order to compute
the right hashring (SRV, time period num from the `ns->valid_after`,
replica, ...).
My investigation lead me to `hs_service_descriptor_t->time_period_num`
value. In theory, every descriptor is _only_ built for a specific time
period, they don't overlap. When we build a descriptor, we keep the time
period num it is built for and then we never change it (which in theory
should be OK). But, descriptor rotation happens at each new SRV which
happens 12h *before* a new time period.
Thus, I believe we have an issue where a descriptor can be between two
time periods leading to something like: Current Desc: `TP - 1`, and Next
desc.: `TP + 1` or something like that which means there is up to a 12h
time frame where the current time period num has simply no descriptor for
it and thus the service is unreachable.
See `build_descriptors_for_new_service()` ... there is something
problematic there where we use `now` to check if we are in between `TP`
and `SRV` and if so, then we get the previous/current time period num but
this time using the `valid_after` ... these can be offset which can lead
to missing a time period num for the descriptor we are building.
I'm running an experiment right now that should confirm the theory. I'll
have results in hopefully less than 48h.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26709#comment:5>
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