Patrick Schleizer: > https://blog.torproject.org/blog/lifecycle-of-a-new-relay At least malicious relays have to stick around a few days to become Guards. > If there aren't any guards hardcoded in > Tor's source code, then the initial fetch from authorities must ignore > the TunnelDirConns option. Can't work any other way. All Authorities are also regular relays. (4 of 10 even have a Guard flag, but I suppose tor only becomes aware of that after it has fetched the consensus.) client -> AuthorityX:ORPort -> AuthorityY:DirPort Maybe the encrypted ORPort / plain DirPort distinction sort of answers your https://tor.stackexchange.com/questions/286#comment311_288 I've narrowed the tor_relays ipset down to all Valid relays with an Authority or Guard flag, and only to their ORPort - no more direct DirPort connections allowed, the tor client doesn't do that by default. > The nice thing about corridor is, that it's still quite simple. > Something I still have my Whonix todo list. (Providing minimal > Whonix-Gateway source code, moving things like whonixcheck, timesync > etc. into separate packages, so others can more easily grasp it, copy > the concept etc.). Let me just make a mental note to keep the WiFi portal thing separate from corridor proper straight away. :) > I am interested to fine tune the following page and add corridor to it > to better visualize the nuances of the differences: > https://www.whonix.org/wiki/Comparison_with_Others > > Time is an issue, though. Perhaps you're interested? No hurry, let's see how corridor turns out. > I am quite intrigued by the corridor concept, it may help to archive > build anonymity: > https://www.whonix.org/wiki/Dev/Build_Anonymity If your build does not depend on the data that's currently leaking through clearnet requests... Rusty
Attachment:
signature.asc
Description: OpenPGP digital signature
-- tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk