[tor-bugs] #30623 [Core Tor/Tor]: may prop 110 + 292 making hs discovery easier?

[Tor Bug Tracker & Wiki]

#30623: may prop 110 + 292 making hs discovery easier?
------------------------------+------------------------------
 Reporter:  cypherpunks       |          Owner:  (none)
     Type:  task              |         Status:  new
 Priority:  Medium            |      Component:  Core Tor/Tor
  Version:  Tor: unspecified  |       Severity:  Normal
 Keywords:  needs-review      |  Actual Points:
Parent ID:                    |         Points:
 Reviewer:                    |        Sponsor:
------------------------------+------------------------------
 I have read both:

  * [http://jqs44zhtxl2uo6gk.onion/torspec.git/tree/proposals/110-avoid-
 infinite-circuits.txt proposals/110-avoid-infinite-circuits.txt]

 {{{
 If an intermediate server receives more than K relay_early cells,
 }}}
  * [http://jqs44zhtxl2uo6gk.onion/torspec.git/tree/proposals/292-mesh-
 vanguards.txt proposals/292-mesh-vanguards.txt]
 {{{

 Additionally, to avoid linkability, we insert an extra middle node
   after the third layer guard for client side intro and hsdir circuits,
   and service-side rendezvous circuits. This means that the set of
   paths for Client (C) and Service (S) side look like this:
 }}}

 and found that with the extra 4th random middle node added by vanguards
 circlen, a onion Service using vanguards does not blend in with other
 services or clients. As each intermediate guards server should passively
 be able to Monitor by listening receives more than usual relay_early cells
 with (plus ) extra vanguard relay_early cell and find out  node's position
 in the circuit is guard for that the connecting or is a hidden Service
 with using vanguards addon enabled easily?
 please check..

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30623>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online