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

Re: [tor-relays] How to use our own TOR relay as entry node for local network hosts



Great points raised there with your post.  Thanks for the reply.

I definitely don't understand everything about Tor but I'm gradually getting there. The public Tor entry guard relay ran great for over a year but we ended up taking it down for a while once I realized something was wrong with how we were trying to use it as our configured EntryNode from clients on the local network. We put it back up a couple few months ago with an updated version and I started twiddling again with the network clients.

I knew something was wrong but couldn't quite put my finger on it until s7r's post - it made sense. For what we were trying to do - use a public Tor relay we know and trust (ours!!! <g>) as our tor client EntryGuard, and also help contribute to the cause, it works great. Our Tor relay is the first node in our circuits now. I just had to stop pointing my clients at the polipo proxy and configure the fingerprint of our public EntryGuard/node in torrc on the clients.

And yea, I am our network admin too. Totally small-time. :)

Thanks again.

On 05/23/2015 06:47 PM, Zenaan Harkness wrote:
On 5/20/15, s7r <s7r@xxxxxxxxxx> wrote:
On 5/20/2015 12:07 PM, Tor User wrote:
If I'm wrong about this, that's great - I'd love to see some
documentation to explain it better if you have any links handy.
But if I'm right, how can I configure our TBB clients to actually
MAKE them use our TOR proxy as their entry node?
I do not see any benefits in using a Guard on your local network, I
just don't see the point of it. You can do the following:

1. The centralized Tor server, as explained above, means you have to
run only one Tor instance for all the computers in your network. This
means you don't need Tor on all of the other computers in your
network, and the entry point (Guard) needs to be defined on the Tor
I think the OP wants to treat their "centralized Tor server" as though
it is a guard, which is why the term "centralized Tor server" perhaps
clarifies the OP's thinking.

As you highlight, with a "centralized Tor server", a separate (local
LAN) "entry guard server" doesn't make sense.

centralized server (in your case relay) only, and it will affect all
the clients in the network using it. You will not be able to see
circuit info (such as path) on the computers using this centralized
Tor server because they won't have access to the Tor control port,
which is totally normal.
The thought still lingers though - if one were to run TBB or a Tor
node on each computer in a LAN, and treat the "centralized Tor server"
as an "entry guard" by some manual configuration:

a) This should be doable, workable, and be just fine/ok or in fact
even better than having all local/LAN computers access Tor/internet
through the SOCKS proxy of the "centralized Tor server",

b) It should be possible to set up such a configuration manually -
force the "centralized Tor server" to be "my" (random LAN PC with tor
instance eg TBB) entry guard to the Tor network, even though it does
NOT have the guard relay, assuming I am the LAN admin, or that I trust
the LAN admin,

c) It should be better for security of each LAN PC - since they are
sort of participating natively in the Tor network, since they begin
their own hop in/at their local PC, and so don't have to rely nearly
so much on the LAN admin and the SOCKS proxy running on that
"centralized Tor server" - is getting from my PC to a SOCKS proxy on
some other PC even secure at all, or is some other security layer now
needed to protect/hide agains LAN eavesdroppers?,

d) Because each LAN PC has its own tor node (eg TBB with manual
config), they can see their full circuits in the wider Tor network -
with all circuits always beginning at the (manually configured)
"centralized Tor server configured as my permanent Tor network entry
guard node",

e) TBB "just works" from a "all the various Tor project customizations
for Firefox are baked in, it's much harder for me to f*** it up
somehow" - and I think this is one of the most critically important
benefits that should not be so readily discarded with:

On the computers in your network you can just use Firefox with some
privacy plugins and route all traffic (including DNS) through the
polipo proxy, running on the Tor centralized server / relay.
since "just install some privacy plugins and route DNS through
SOCKS/polipo" can so easily fail big time!

If there's any chance of adversarial eavesdropping or browser attacks,
surely you want to start from a "just works as far as most Tor devs
are aware within the known limits etc" position, and add the minimal
browser config/ manual Tor config on top of that?

What happens when a TBB security fix comes out - does one assume that
normal firefox does not need that? Does one assume that a normal
firefox upgrade, in the face of the full set of manual "TBB like"
customizations (assuming you even implemented them all, and
implemented them all correctly) and that you do -not- need to do a
full firefox reinstall?

There are SO many unanswered security questions for an end user (or
LAN admin trying to be responsible on behalf of their LAN PC users)
that I feel it is dangerous to suggest something other than "use TBB,
with absolute minimal manual config on top, e.g. disable Javascript
:)"!

...
Want a centralized Tor server and a Guard relay at the same time? Just
run the relay someplace else, and use StrictNodes and EntryNode on
that server. I doubt this is what you want since you installed Tor
Browser on the computers in the network as well.
TBB, albeit with some (hopefully minimal) manual customizations, ought
be "the recommended way" by my reasoning... the only question is how
to achieve a sane setup, optimizing for a particular scenario - in
this case, the OP is optimizing for a LAN environment in which it
appears that the OP may be the admin, and therefore that the OP has a
certain trust in him/her self :)

It might, just possibly, also be the case that other individuals who
use that LAN environment, place some level of trust in their LAN admin
too.

In the face of even a minimal level of additional trust which is not
ordinarily available to Joe Random Home User, surely it is sensible to
try to leverage that additional trust in order to maximise "security
(by some definition)"?

And here, I feel, is the crux of both a dilemma, and an opportunity,
which is highlighted by the OP, and which Tor network has failed to
confront or take advantage of - actual available trust in a particular
node operator (in this case the OP's "centralized Tor server").

Perhaps the old vidalia (?) setup where there was a separate gui for
TBB's Tor networking side did provide a mechanism for end users to
take advantage of such "additional available trust"? Before my time
sorry.

...
You can run a centralized Tor server with polipo and a Tor relay on
the same server, but that Tor client
"that Tor client" is ambiguous to me and I can't figure out what you
mean - if you think it's useful, please clarify what you meant by
"that Tor client".

cannot use its relay
functionality running on the same machine as the first hop.

2. Disable the polipo proxy on your Tor relay, you do not need that.
I agree with this. Tor server (relay/"centralized Tor server"/"faux
Tor entry guard") provides a SOCKS proxy built in - I see only
disadvantages to adding an unnecessary additional proxy layer.

Use Tor Browser on every computer in your network with normal
settings, no proxy setup, just direct connection
By "direct connection" do you mean "direct/normal automatic connection
to the Tor network"?

and StrictNodes and
EntryNode $fingerprint-of-your-relay.
Ahah! This sounds like what the OP is after - what I term above as
"faux Tor entry guard".

For this, your relay needs the
Guard flag.
Oh. Dang.

So what's wrong with having:
EntryNode $cntrlzd-faux-guard-relay-fingerprint
ForceEntryNodeIfNoGuardFlag true

???

If you are behind NAT, it will use the public IP to
connect to the relay on your network since that is what your Tor
client(s) will understand from the consensus data file.
What's wrong with the fingerprint? Surely this is some sort of public
key verifiable fingerprint, crypto 101 right?

In other words:

EntryNode $cntrlzd-faux-guard-relay-fingerprint
ForceEntryNodeIfNoGuardFlag true
EntryNodeAddress 192.168.1.207

???

(I'm not asking why doesn't it work now, since these additional
options probably don't exist in Tor yet - I'm asking -why- such
options are not a good idea in these circumstances and why this ought
not be permitted at all.)


3. Disable the polipo proxy on the Tor relay in your network,  you do
not need that. Run a bridge instead of a relay. Make it a non public
bride (PublishServerDescriptor 0) and run Tor Browser on all the
computers in your network with UseBridges 1 and define the ip:port of
your bridge and connect it directly, no proxy setting. This way other
'strangers' won't be able to use your bridge and you will also not
need the Guard flag or uptime and bandwidth requirements.
Sounds like another "ahah!" moment - perhaps this is finally the
answer to OP's need.

Hope this helps.
That last bit (UseBridges 1, configure bridge IP), looks like it does
the job needed here, no new Tor config options required.


If you don't understand something, please ask again,
it's important for you to understand what you are doing not just
follow instructions.
ACK. I too want to understand, which makes at least 2 people :)

Regards,
Zenaan
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays