Differences

This shows you the differences between two versions of the page.

--- fuss:tor [2014/11/24 01:16] – [Last Update: March 10, 2012] office
+++ fuss:tor [2025/02/26 04:25] (current) – office
@@ Line 1: / Line 1: @@
-===== Speed =====
+====== Speed ======
 Some optimisations are possible, for example:
@@ Line 37: / Line 37: @@
 Then you can perform your own speed tests and start to eliminate countries that are slow for you. A good resource is the [[http://www.netindex.com/download/allcountries/|net index by ookla]] which provides a very generalised overview of internet quality based on upload and download statistics.
-==== Systematic Approach ====
+===== Systematic Approach =====
 ''TOR'' tries to build a circuit in the time specified by the setting:
@@ Line 52: / Line 52: @@
 Also note that the ''CircuitBuildTimeout'' has a direct relation to your privacy since you will find the shortest circuits using this method, but you will also end up using them frequently. However, it will still mask your IP address and if that is your unique consideration, then you can safely set ''CircuitBuildTimeout'' to ''1''.
-==== Speed Patches ====
+===== Speed Patches =====
 These are various patches, hacking around tor (most likely breaking anonymity in favor of speed). The patches are against the git version but similar code can be found in the release versions.
-=== Close Nodes ===
+==== Close Nodes ====
 tor defines the option ''EnforceDistinctSubnets'' (and enabled by default) in order to not build a circuit through a ''/16'' netmask. This patch changes that restriction to a ''/24'' netmask (''255.255.255.0'').
@@ Line 77: / Line 77: @@
 This can be found in ''routerlist.c'' on tor version ''0.2.3.25''.
-=== Circuit Length ===
+==== Circuit Length ====
 Allow ''2''-hop circuits instead of ''3''. It is not clearly defined how many hops will protect your anonymity (except for the general "the more, the merrier" guideline). So, why not use ''2'' hops instead of ''3'' - or increase this value for longer circuits.
@@ Line 96: / Line 96: @@
 </code>
-===== Bad Nodes =====
+====== Bad Nodes ======
 There is an ''.onion'' website that advertises itself as a judge of bad nodes, it can be found at:
@@ Line 105: / Line 105: @@
 and they can be used to generate ''ExcludeNodes'' and ''ExcludeExitNodes'' configuration lines for Tor - obviously, you cannot be sure whether these generators are trustworthy.
-==== Last Update: March 10, 2012 ====
+===== Last Update: March 10, 2012 =====
 The following is a generated list of fingerprints that are deemed to be misbehaving. The site above was last active on March 10, 2012 so this list may be outdated. The two lists below should be added to the Tor configuration file:
@@ Line 119: / Line 119: @@
 an effective solution is to add the ''StrictNodes 1'' option to the Tor configuration file as well to ensure that these nodes are never used.
-===== Enable Hardware Acceleration =====
+====== Enable Hardware Acceleration ======
 To get list of engines, first issue:
@@ Line 140: / Line 140: @@
 in order to use a given engine.
+Under FreeBSD, you should load the ''cryptodev'' module:
+<code bash>
+kldload cryptodev
+</code>
+which should give you access to the ''cryptodev'' FreeBSD engine. You can make loading the module automatic by loading it from ''loader.conf''.
+====== Updated Debian Packages ======
+To install the latest Debian package from ''torproject.org'', first create a file at ''/etc/apt/sources.list.d/tor.list'' with the following contents:
+<code>
+deb http://deb.torproject.org/torproject.org stable main
+</code>
+After that, import the GPG key for the repository by issuing the following commands:
+<code bash>
+gpg --keyserver keys.gnupg.net --recv 886DDD89
+gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | apt-key add -
+</code>
+Now update the sources list:
+<code bash>
+aptitude update
+</code>
+and upgrade:
+<code bash>
+aptitude upgrade
+</code>
+====== Compile a Static Tor ======
+First download the relevant packages:
+  * Tor
+  * OpenSSL
+to, say ''/usr/src''. Then compile OpenSSL:
+<code bash>
+./config ec_nistp_64_gcc_128 shared zlib-dynamic --openssldir=/usr/local/openssl
+</code>
+Note that ''ec_nistp_64_gcc_128'' enables elliptic-curve cryptography and it can be used by Tor.
+then you may need to run:
+<code bash>
+make depend
+</code>
+and then to compile issue:
+<code bash>
+make
+</code>
+and finally:
+<code bash>
+make install
+</code>
+which will place openssl into ''/usr/local/openssl''.
+The next step is to compile tor statically:
+<code bash>
+./configure --prefix=/usr
+            --sysconfdir=/etc
+            --localstatedir=/var \
+            --enable-upnp  \
+            --enable-nat-pmp \
+            --enable-bufferevents \
+            --enable-static-openssl \
+            --with-openssl-dir=/usr/local/openssl \
+            --enable-static-libevent \
+            --with-libevent-dir=/usr/lib/x86_64-linux-gnu
+</code>
+In case ''--enable-static-tor'' is enabled then ''tor'' may bomb out with: ''configure: WARNING: Could not find a linkable openssl.'' which does not seem to go away.
+====== Increase Logging ======
+When debugging Tor, in particular client transport plugins it is sometimes useful to increase logging in order to determine the cause for something not working right.
+Locate the configuration line starting with ''Log'' and change the next parameter ''notice'' to ''debug''. For example, change:
+<code>
+Log notice syslog
+</code>
+to:
+<code>
+Log debug syslog
+</code>
+The previous configuration line will turn on debug logging and will send all messages to the system log.
+====== Monitoring tor Health Status ======
+When scaling up and using load balancing and high availability it is important to have a decisive way to determine whether a backend service is alive or not. Usually checks vary from "weak", for example, checking the PID of the process required, to "strong" assumptions, for example, checking whether the service responds properly, with stronger results always being more preferred.
+In case of tor, given the inner workings, the strongest way perhaps to know whether tor is available, is to check whether a circuit has been established, which should indicate whether a client using tor as a proxy will be able to request an address through tor.
+In order to do that, the tor control port and password have to be defined in the tor configuration file (usually at ''/etc/torrc''). First, a tor password must be generated in order to be able to access the tor control port by using the following command:
+<code bash>
+tor --hash-password "tor"
+</code>
+which will result in a password generated on the standard output:
+<code>
+:9F840FFC85EF83CE60469C431DC9FF43DB889305B7653C2CB653302594
+</code>
+The password will then be added to the tor configuration:
+<code>
+ControlPort 8050
+HashedControlPassword 16:9F840FFC85EF83CE60469C431DC9FF43DB889305B7653C2CB653302594
+</code>
+After restarting tor the control port can be accessed via TCP and the status of the circuit can be checked. Here is a full TCP transcript using netcat:
+<code>
+$ nc -nv 192.168.1.1 8050
+Connection to 172.16.1.81 8050 port [tcp/*] succeeded!
+AUTHENTICATE "tor"
+OK
+GETINFO status/circuit-established
+-status/circuit-established=1
+OK
+</code>
+where:
+  * ''192.168.1.1'' is the IP of the machine running the tor instance,
+  * ''8050'' is the port opened by tor that can be configured via the ''ControlPort'' configuration directive in ''torrc''
+The useful string to look for in the responses is ''250-status/circuit-established=1'' and the value ''1'' indicates that a tor circuit is established.
+===== Monitoring Tor Instances with Monit =====
+With the configuration in place, tor is restarted and the following monit configuration is created:
+<code>
+###########################################################################
+##  Copyright (C) Wizardry and Steamworks 2023 - License: GNU GPLv3      ##
+###########################################################################
+check process tor-01 with pidfile /var/run/tor-instances/01/tor.pid
+   start program  "/bin/systemctl restart tor@01"
+   stop program  "/bin/systemctl stop tor@01"
+   if failed host 127.0.0.1 port 9050 type tcp then restart
+   if failed host 127.0.0.1 port 8050 type tcp and
+      # password is: tor surrounded by quotes 0x22
+      send "AUTHENTICATE \0x22tor\0x22\n"
+         expect "250 OK"
+      send "GETINFO status/circuit-established\n"
+         expect "250-status/circuit-established=1"
+      retry 1
+      timeout 5 seconds
+      then restart
+</code>
+that will restart tor in case a circuit is not built within two minutes (60 seconds standard monit check time and times two for one more retry).
+===== Monitoring tor Instances using Expect =====
+A more versatile variation of the [[/fuss/tor#monitoring_tor_instances_with_monit|monit tor monitoring system]] is to use good old "expect" in order to make sure that tor has an established circuit and to take action.
+<code>
+#!/usr/bin/expect -f
+###########################################################################
+##  Copyright (C) Wizardry and Steamworks 2024 - License: MIT            ##
+###########################################################################
+# This is an "expect" script that checks whether tor has established a    #
+# circuit and sets the return status depending on whether it has or not.  #
+#                                                                         #
+# In other words, iff. the script returns 0, then tor has an established  #
+# circuit; otherwise no circuit has been established.                     #
+#                                                                         #
+# Requirements:                                                           #
+#   * expect (TCL program)                                                #
+#   * tor must expose a control port and must have a control password     #
+#                                                                         #
+# In order to generate a control password, issue: tor --hash-password PWD #
+# where PWD is the desired control port password. After that, amend the   #
+# tor configuration file to set the control port address, port and pass:  #
+#                                                                         #
+# ControlPort 0.0.0.0:8050                                                #
+# HashedControlPassword 16:A482ADEAAWF43EE...                             #
+#                                                                         #
+# Running: ./this-script ADDRESS PORT PASSWORD                            #
+# where:                                                                  #
+#   * ADDRESS is the tor listening control address,                       #
+#   * PORT is the tor listening control port,                             #
+#   * PASSWORD is the plaintext control password                          #
+#                                                                         #
+# after which the return status can be checked on the shell with:         #
+# echo $?                                                                 #
+###########################################################################
+set address [lindex $argv 0];
+set port [lindex $argv 1];
+set password [lindex $argv 2];
+set timeout 5
+spawn telnet $address $port
+send "AUTHENTICATE \"$password\"\n"
+expect "250 OK\r\n"
+send "GETINFO status/circuit-established\n"
+expect {
+    timeout {
+        exit 1
+    }
+    -ex "250-status/circuit-established=1\r\n250 OK\r\n"
+}
+</code>
+====== Load-Balancing Multiple Tor Instances via HAProxy ======
+When running multiple Tor instances, it is possible to load-balance the traffic over all Tor instances whilst having a single SOCKS entry point.  For instance the proxy chaining page shows [[/networking/proxy_chaining|a configuration that leverages squid and polipo instances]] in order to load balance the traffic accross multiple Tor instances whilst the [[/linux/running_multiple_instances_of_a_daemon|multiple instances page]] demonstrates how to run the same program multiple times while maintaining System D compatibility.
+Nevertheless, there are simpler setups possible by using HAProxy that is able to load balance across multiple SOCKS servers. By contrast, ''privoxy'' is a smaller proxy but uses pattern matching to spread the traffic over backends without actually being able to load-balance over multiple SOCKS connections.
+<ditaa>
+                                  . multiple Tor instances
+                                  .
+                             +---------+
+        +---------+     +----+   Tor   |
+        |         |    /     +---------+
+ SOCKS--+ HAProxy +---+           .
+        |         |    \     +---------+
+        +---------+     +----+   Tor   |
+                             +---------+
+                                 .
+                                 .
+</ditaa>
+Assuming that multiple Tor instances are set up to listen to an array of ports, HAProxy can be set up with the following minimal configuration changes:
+<code>
+defaults
+        mode tcp
+        option redispatch
+listen socks5-balance
+        bind    0.0.0.0:9050
+        balance leastconn
+        server socks5-1 127.0.0.1:9051 check
+        server socks5-2 127.0.0.1:9052 check
+</code>
+The configuration declares two upstream proxies on ''127.0.0.1'' and listening on port ''9051'' respectively ''127.0.0.1'' and listening on port ''9052'', listens on ''0.0.0.0'' on port ''9050'' and will proxy all traffic between the declared SOCKS servers with the following options:
+  * ''balance leastconn'' - the balancing method chosen in ''leastconn'' that will attempt to distribute the load across the two declared SOCKS proxies. However, ''leastconn'' relies on log-term connections in order to distribute weights across the SOCKS servers such that ''roundrobin'' could have been chosen instead.
+  * ''option redispatch'' - makes HAProxy retry proxies in case one of the backends fail.
+Finally, by pointing an application at the HAProxy port ''9050'', the connection should be spread amongst the declared SOCKS backend servers. Depending on the distribution configuration, the log files can be observed to make sure that the traffic is properly redirected.
+===== Availability =====
+Based on [[/fuss/tor#monitoring_tor_health_status|checking the tor status]], it is also possible to make backend checks stronger in order to determine whether a certain tor instance should be used or not. The HAProxy configuration proposed just uses a port check on the tor socks port in order to determine whether the tor instance is running, however that check is weak, checking just connectivity, and it is possible to make the check stronger by polling tor for the circuit status.
+The tor configuration must be updated in order to open up port ''8050'' as a control port as well as specify the password as a hash:
+<code>
+ControlPort 8050
+HashedControlPassword 16:9F840FFC85EF83CE60469C431DC9FF43DB889305B7653C2CB653302594
+</code>
+For each additional tor instance, a program will be running that will serve the tor circuit status over TCP:
+<code bash>
+socat TCP-LISTEN:7050,fork,reuseaddr exec:"/usr/local/bin/tor-check-circuit 127.0.0.1 8050 tor
+</code>
+where:
+  * ''7050'' is a port that a client can connect to in order to find out the status of the tor circuit,
+  * ''tor-check-circuit'' is a script that uses "expect" to check tor for the tor circuit and an example thereof can be found [[/assets/docker/build/tor-snowflake#tor-check-circuit|on the tor Docker build page]],
+  * ''8050'' will be the port opened up by each tor configuration (usually ''torrc'') by specifying ''ControlPort 8050''
+Finally the HAProxy configuration file should be changed to:
+<code>
+defaults
+        mode tcp
+        option redispatch
+listen socks5-balance
+        bind    0.0.0.0:9050
+        balance leastconn
+        server socks5-1 127.0.0.1:9051 check weight 100 agent-check agent-port 7050 agent-inter 1s
+        server socks5-2 127.0.0.1:9052 check weight 100 agent-check agent-port 7050 agent-inter 1s
+</code>
+The mechanism will ensure that each ''socat'' instance will return either ''100'' when a circuit is established and ''0'' otherwise, which, in turn, will allow HAProxy to dynamically change the weight of the given tor instance.
+Incidentally, the same same balancing scheme has been used for [[/networking/leveraging_docker_swarm_for_high-availability_and_load-balancing_services|load-balancing Apache servers within Docker containers]] and the same principle is leveraged here, just that the ''tor-check-circuit'' script will only return ''100'' or ''0'' with weights only varying from "available" (100) to "none" (0), instead of actual "weights" using the full range between ''0'' and ''100''.