[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #30623 [Core Tor/Tor]: may prop 110 + 292 making hs discovery easier?
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs