[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #20262 [Core Tor/Tor]: Onion services startup time always gets revealed
#20262: Onion services startup time always gets revealed
-----------------------------------------------+---------------------------
Reporter: twim | Owner: twim
Type: defect | Status:
| needs_revision
Priority: Medium | Milestone: Tor:
| 0.3.0.x-final
Component: Core Tor/Tor | Version:
Severity: Major | Resolution:
Keywords: tor-hs, research, review-group-11 | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor: SponsorR-
| can
-----------------------------------------------+---------------------------
Comment (by twim):
Replying to [comment:15 asn]:
> I handle dozens of trac tickets every week. The fact that #20262 and
#20082 change the exact same part of the codebase for different reasons
and are being developed at the same time, confuses me _a lot_ since I
can't remember what's the rationale for each change and which ticket I
should consult.
> All in all, I feel like the security rationale for this bugfix is
sprinkled over two different trac tickets and a mailing list thread, and
this makes it very hard to understand why the changes are as is. Also the
code patches seem more complex than they need to be and a bit hard to
follow.
Sorry for leaving this ticket as `needs_review` because it supposed to be
based on the code after fixing `rend_consider_services_upload()` code in
#20082. This one and #20082 were closely related in the beginning but
after it all bifurcated due to the fact that there are two purposes of
initial post delay:
* (part of #20082) Unlink multiple onion services running on the same
tor instance by not uploading all the descriptors at the same time
(following spec)
* (#20262) Obfuscate/hide exact startup time in `[0:2*RendPostPeriod]`.
It should be an optional feature. That's why there is torrc option here.
> And talking about threats, if we don't insert a delay, who is the
attacker here? Who can actually link the multiple HS instances? Their
descriptors will go to different HSDirs most probably, so it's probably
not the HSDIr. Who is the attacker? I still have not seen a proper
security analysis here...
It's the purpose of #20082 and this discussion should be done there (see
above).
Sorry for the mess. :\
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20262#comment:17>
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