-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Rusty Bird: >> It's an documented and automated process. > > What is that process?
https://blog.torproject.org/blog/lifecycle-of-a-new-relay https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1768 (search for "Guard") >>> But a freshly installed Tor client will not necessarily fetch >>> its first consensus through a Guard, right? > >> Some guards and directory mirrors are hardcoded in Tor. > > I only see the directory authorities, what code bakes in guards > and directory mirrors? If you meant the authorities, how about > limiting the ipset to relays with a Guard *or* an Authority flag. I might be wrong about this. 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. https://tor.stackexchange.com and this mailing list are good places to ask such specific questions. If such a question doesn't get satisfactory answers when asked inside a topic as this one, I advise to start a new topic which is only about this question. Generally it is my impression, that repeating questions that may be found on search engines after after a while aren't as welcome on mailing lists as they are on stackexchange, which is more lenient and has "let's ask and answer all on topic questions" kind mindset. I guess no one else answered here, since this thread is pretty specific and perhaps ignored by others that may better know such Tor design basics. >> Corridor's advantages: - streams from different workstations can >> never share a circuit > > The more essential point is that client computers don't have to > trust the corridor gateway to provide anonymity. That's huge if > you're offering your internet connection to strangers: Their only > choice if they don't trust a *proxying* gateway would be to run Tor > over Tor. Interesting consideration. >> Whonix's advantage: - malicious software on the workstation can >> not find out it's real external IP address > > With a filtering gateway (corridor), a malicious software M on the > client computer can instantly and directly contact a colluding > relay. > > With a proxying gateway (Whonix), M can only do that when the > gateway uses that relay as a Guard, and M has to open a covert > channel, e.g. request/response timing. > > Kudos to you for bringing this issue to light. I will document > that corridor cannot prevent well-orchestrated leaks, and that > there is no replacement for securing your client computer (which > was never my intention to imply). You didn't imply, but I am conditioned to believe all Tor-gateway like projects attempt to do this. It's nice to see innovation, that focuses on orthogonal issues. >> I am wondering, can we get both advantages using just one >> gateway? > > If you also count the question of who to trust, yourself (the > client) or the gateway, then with just one gateway, no. Whoever you > trust more is who you want to build your circuits. > > Still, you can put corridor between your Whonix box and your > modem/ router (or directly on the latter if don't use clearnet at > all) as a simple fail safe mechanism: 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.). 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? I am quite intrigued by the corridor concept, it may help to archive build anonymity: https://www.whonix.org/wiki/Dev/Build_Anonymity -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJTAMj5XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2RTk3OUIyOEE2RjM3QzQzQkUzMEFGQTFD QjhENTBCQjc3QkIzQzQ4AAoJEMuNULt3uzxItUAP/0EGx9J4YkNrr+o72E4XeEqk RHa+2S/2sfjoFMeMvZN2wDO8hm2y6DVwcPtLM2UtLipJR4FeiUxs/i+4DstZglyw 5gOsBr6WNdblGDn2vFFd85PL1Jmj8gYFqYT+GuAjISQfgadvAIcUTtHyb6cnB5K6 0FoKbziIa5QhDdvTPSpjrnDfgARS2gzTh+l4h/Jwoa2lV6JFUGoBw5vJU2f8wnYM K0AbCQnDir3MCgxyncVRkQ2oqSlSD7tLuDY/Vsfd7I+VNA6mF7zTSvDJMQy+ykxw JdiyzKvMKLb20//j7jM7A3vIs0/Awyi8bbnLiFVc8faw6LICyaTp4Iw7+IbCenpS OVoAjF0lwu3R2pFJAyFfiM+1XYXFGQsvKyBc0lMb2sNHBm2AE0v5icCNS/UNwu3C 21F2cIAXxdVIjacfzthLV2gl/XvM7bxRQlGgP8YYs5KWFV8ZA04UUszIRZW9In25 Etb8Jl+GPQdXF/Ppgk+WNOQcXWC+Miks8RfyRiGo8k5C4d+hILX4LkYH35T+v2jp TQpPHAtmJxL8EIe3zH4D6Tra/HQOR0R2jBKYROg5TUZW4apNYPdv3vm1Q0ZGaKZd SAV5iQmmsgNqh9Aj9xDnzWtEVDZj8xy0hfoXc59b6cjCu7U691LXz2mMnM7R6uaz khfsSx0dpSss1GbnMBUQ =l8gb -----END PGP SIGNATURE----- -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk