Re: [tor-talk] corridor, a Tor traffic whitelisting gateway

[Patrick Schleizer <adrelanos@xxxxxxxxxx>]

-----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@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk