[tor-relays] How to use our own TOR relay as entry node for local network hosts
toruser at lvwnet.com
Fri Jun 5 02:46:32 UTC 2015
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. :)
On 05/23/2015 06:47 PM, Zenaan Harkness wrote:
> On 5/20/15, s7r <s7r at sky-ip.org> 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,
>> 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
> 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
>> 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 :)
> tor-relays mailing list
> tor-relays at lists.torproject.org
More information about the tor-relays