[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #25552 [Core Tor/Tor]: prop224: Onion service rev counters are useless and actually harmful for scalability

#25552: prop224: Onion service rev counters are useless and actually harmful for
scalability
----------------------------+----------------------------------
 Reporter:  asn             |          Owner:  (none)
     Type:  defect          |         Status:  new
 Priority:  Medium          |      Milestone:  Tor: unspecified
Component:  Core Tor/Tor    |        Version:  Tor: 0.3.1.9
 Severity:  Normal          |     Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:                  |         Points:  4
 Reviewer:                  |        Sponsor:
----------------------------+----------------------------------

Comment (by asn):

 WRT the replay cache idea of step (a) above, we probably do need a replay
 cache on the HSDirs, because there is a 24 hour window (before we change
 blinded pubkey) where HSDirs can replace the descriptors on other HSDirs
 with older versions of the descriptor. We probably want to avoid this and
 we should use a replay cache for this.

 The right way to use a replay cache here is to store the hash of the HSV3
 descriptor on the replay cache. '''We should investigate''' whether we
 need to hash the whole descriptor, or the whole descriptor minus the
 signature (in case the signature is malleable and an attacker can tweak it
 to bypass replay cache). If we need to do the latter approach, we should
 add the right data in `hs_cache_dir_descriptor_t` as part of
 `cache_dir_desc_new()`.

 Implementation plan for step (a) above:

 1) Introduce a global `replay_cache_t *hs_cache_replay_cache` in
 `hs_cache.c` next to `hs_cache_v3_dir`. We should index entries to this
 replay cache by blinded key, or maybe add an insertion timestamp so that
 we know when to clean it up.
 2 In `cache_store_v3_as_dir`, remove the revision counter check, and
 instead query the replay cache for whether we already have seen this
 descriptor before. If we have seen this descriptor before we should treat
 it the same way we treat descriptors with a smaller or equal revision
 counter right now, that is, reject them and `log_info`.
 3) We should clean up the replay cache when we are sure that the blinded
 key for a descriptor is now useless and will never be used by clients
 again. We should look in `rend-spec-v3.txt` to make sure when that is;
 probably at 24 or 48 hours or so.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25552#comment:3>
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