How to use our own TOR relay as entry node for local network hosts
Hello, We have been operating a moderately successful public tor relay for a while now. Having read about how TOR works back a couple of years ago, I was more or less sold on the idea that if traffic originating on your local network uses your own TOR relay as the first hop (entry node), then by the time your traffic has left your tor relay, people in the middle can't tell the difference between traffic originating from your network and other (relayed) traffic passing through your TOR relay. I also understand that this still doesn't protect you from an exit node being able to see your traffic (and why you should use HTTPS with a high-quality cipher if it's really important), and that there are other ways your traffic can be analyzed -- but all in all, I would rather our TOR traffic enter the TOR network through a relay I *KNOW* I can trust (mine!) than leave it to chance. We have polipo running on our public TOR relay, configured to accept traffic from our local subnets. We've basically followed the info in this TOR doco: https://trac.torproject.org/projects/tor/wiki/doc/CentralizedTorServer The TOR browser bundle appears to function correctly, ie, it is able to start up, open circuits, etc. and we get the expected Congratulations! page opening a new browser window. But when clicking the green onion to show the circuit of relays handling the browser's connection, our relay is never the first hop. I'm using TBB 5.01a on one particular system, and for an example, it shows this for the circuit: - This browser - Austria (aa.bb.cc.dd) - Germany (ee.ff.gg.hh) - Guatemala (ii.jj.kk.ll) - Internet I have tried defining an EntryNodes statement with the $fingerprint of our TOR relay and setting StrictNodes 1 in the TBB's torrc file, but it can't ever establish a circuit when I try this. We get messages like this logged on the browser's tor: 05/20/2015 04:21:20.700 [WARN] Failed to find node for hop 0 of our path. Discarding this circuit. 05/20/2015 04:21:20.700 [WARN] Failed to find node for hop 0 of our path. Discarding this circuit. 05/20/2015 04:21:20.900 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150 05/20/2015 04:21:20.900 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 05/20/2015 04:21:20.900 [NOTICE] Closing old Socks listener on 127.0.0.1:9150 05/20/2015 04:21:21.700 [NOTICE] Delaying directory fetches: DisableNetwork is set. Is it possible to define your desired entry node via IP address and port, or some other way that does not require a successful directory connection/circuit first? (so it can find the relay by its fingerprint)? It seems like a chicken vs. egg problem... Or what about defining a directory for the client to use by its IP/port? We are operating a public directory as well. I can't find any info about this or other approaches anywhere. So I always end up removing the EntryNodes and StrictNodes statement from TBB's torrc file, leaving only the HTTPSProxy aa.bb.cc.dd:<polipo-listen-port> statement in there with the DataDirectory, GeoIPFile, and GeoIPv6File statements. It gets the TBB's on our network to the local polipo proxy, which in turn forwards the traffic to our public TOR relay. TBB works fine, but I don't think our TOR relay is the one getting to see our traffic with the original source address with this setup. It is definitely possible, likely even, that I am misunderstanding parts of how this is supposed to work or how a central TOR relay/proxy is supposed to be configured. But it doesn't seem to me that proxying our local network's TBB clients' traffic through the polipo instance on our public TOR relay means that our TOR traffic is being "anonymized" as to where it originated from before it gets to the first node in the circuit - or we would be seeing our TOR relay as the first hop when we look at the circuit in "the green onion button". 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? Thanks, Tor User
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, On 5/20/2015 12:07 PM, Tor User wrote:
It's Tor, not TOR or tor.
You could run your own *Exit* node on your network, and use that as a static exit point, which will mix the traffic in your local network with the traffic of other Tor users, and you won't have to fear that the Exit node you are using is malicious and is logging your traffic or doing strange stuff with it.
The way I understand it, it looks to me that you are confusing 2 things. When you enabled polipo on the Tor relay in your network, you just enabled a http-proxy which forwards the requests to the Socks5 proxy opened by the Tor client running on that relay (same Tor instance). When you run a Tor relay, the client functionality is also enabled by default, unless you specify SocksPort 0 in the torrc file. The Centralized Tor Server allows you to have one Tor client/instance for multiple computers in the same network. You need to run only one Tor instance on one server, and the other users in the network do not need to run own local Tor client instances, otherwise they will just be using Tor-through-Tor which is a terrible idea and it hurts anonymity in an unknown way. The relay you are running can never be the first hop, because the second Tor client running on your workstation is selecting another first hop and it is using it through the polipo proxy you've provided. In simple words, you are doing Tor-through-Tor and it is very very wrong .
Of course, you are trying to connect to server let's call it 'Bob' via a polipo proxy running also on the same server 'Bob', e.g. trying to connect back to self in a strange way which Tor forbids for security reasons.
No, that is not possible. Does your relay have the Guard flag so it can be used as the first hop? Check on https://atlas.torproject.org/ and let us know what flags you have for your relay. It needs to be fast and up most of the time in order to get the Guard flag.
I explained above why. You are using Tor through Tor. Running a Tor client on a computer in your network via another Tor client running in the same instance with the Tor relay (and polipo proxy).
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 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. 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. If the centralized Tor server is also a relay, it cannot also be its first hop. E.r. client -> relay-on-the-same-instance-as-client -> middle -> exit ;; this will not work for obvious reasons. 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. You can run a centralized Tor server with polipo and a Tor relay on the same server, but 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. Use Tor Browser on every computer in your network with normal settings, no proxy setup, just direct connection and StrictNodes and EntryNode $fingerprint-of-your-relay. For this, your relay needs the Guard flag. 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. 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. Hope this helps. If you don't understand something, please ask again, it's important for you to understand what you are doing not just follow instructions.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJVXGppAAoJEIN/pSyBJlsRFIkIAL7RhIy3k2uIzq/4AsLCyHw4 K1WsLY6MFOqKyA/PgCXNWsBvr4P5v1VU3HbTH8Iq5dLMJBD1NAanAl4+ViLR1pkL n8pXtzNjbatjMfaUw5wVuCm3MawpahWu9f93k131tUeHKj9/NhwEiZ1aA6Ffavwc 6S+9/yF2aGzRW0wlRNsi2gN/zOIYvI4ANHiq+vfVtwBioymYg+LIfsMaSaHVvNR4 o7xkmERQu6fzadS8iPpoKrZ8c6net49BLJL49z1gWcYRv00Qinj3wcSRZ2tZp0te I4GaKyTx9IGcuS+oWgqPS8agjCnyxI6l3b1mCNsiKKkv8KsqFQ3D399rUAs5vHE= =ANcS -----END PGP SIGNATURE-----
Hi s7r, Thank you for your reply. There's a lot of good info in it and I'll be reconfiguring the clients. The fact that I've been doing Tor-through-Tor unawares explains a lot. It did seem odd to have polipo in the mix, but it makes sense now, that would only be if the LAN clients weren't already running their own Tor clients (running TBB). Our public Tor relay is an entry guard. We don't allow any exiting with it but it's stable, fast, HSDir, etc. and has the guard flag. On 05/20/2015 07:05 AM, s7r wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Glad you understood what you are doing wrong. In this case, you can use your relay as a guard for the clients in your network. See in my previous email suggestion #2, and all your clients will have the desired guard. Install Tor browser on each client and don't use proxy setting, connect directly with StrictNodes and EntryNode. Cheers! On 5/23/2015 3:14 PM, Tor User wrote:
iQEcBAEBCAAGBQJVYMkrAAoJEIN/pSyBJlsRqxgH/jDCZLkFSzX6xcLje8npVnW4 70gEy5UPufyeE6oGvWEK3of9lFTFOHyYy5jWk33vDVLOYnHzZiecoHHpxtSH/vno 6C7SpGN7u6FkVwoYQdACDaswkkDLCCZTZbJ/BD4rpdPVkstd1NiObHeXrwZSQT0U hgKPZGwUrOuotnzLLdu4g7PBRuAqD1CUBbKaLOg77GG9d+luP2yhtWCJ/zQlarK+ PohH9k/IE7dAxUUBiwJV2JeZDadxt4FgRMYuwmD2sCXAvzGvPoqDhdAOBa90vpr+ d9m328C+d+3FHmy9dy8j9a9jLwUAIOIGezZrRaOoBEAku4ExF3WWm0eojQski3c= =1r4z -----END PGP SIGNATURE-----
On 5/20/15, s7r <s7r@sky-ip.org> wrote:
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.
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:
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 :)"! ...
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".
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 ???
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.)
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.
ACK. I too want to understand, which makes at least 2 people :) Regards, Zenaan
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:
participants (3)
-
s7r -
Tor User -
Zenaan Harkness