[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

Hash: SHA512

Rusty Bird:
>> It's an documented and automated process.
> What is that process?

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:

Time is an issue, though. Perhaps you're interested?

I am quite intrigued by the corridor concept, it may help to archive
build anonymity:


tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to