Tor
Contents
- 1 Version Number
- 2 Permissions on directory /var/run/tor are too permissive Error
- 3 Log Analysis
- 4 See Also
- 5 Advanced Topics
- 5.1 Entry Guards
- 5.1.1 Introduction
- 5.1.2 Guard Fingerprinting
- 5.1.3 Manual Rotation of Tor Guards
- 5.1.4 Mitigate the Threat of Guard Fingerprinting
- 5.1.5 Clone Whonix-Gateway (sys-whonix) with New Entry Guards
- 5.1.6 Regenerate the Tor State After Saving the Tor State Folder
- 5.1.7 Alternating Bridges
- 5.1.8 Copy Tor Configuration files and Settings to Another sys-whonix Instance
- 5.1.9 Fresh Tor Entry Guards by Regenerating the Tor State File
- 5.1.10 Configure Non-Persistent Entry Guards
- 5.1.11 Notes
- 5.2 Blacklist Certain Onion Services from Connecting
- 5.3 Additional SocksPorts
- 5.1 Entry Guards
- 6 UDP
- 7 Reload Tor
- 8 Restart Tor
- 9 Disable Tor
- 10 Footnotes / References
Version Number[edit]
To discover what Tor version is currently in use, run the following command inside Whonix-Gateway (Qubes-Whonix: sys-whonix).
The output should be similar to the following.
INFO: version of the 'tor' package: 0.3.2.10-1~d80.jessie+1
Permissions on directory /var/run/tor are too permissive Error[edit]
To discover if you are affected by the Permissions on directory /var/run/tor are too permissive error, [1] run the following command inside Whonix-Gateway (Qubes-Whonix: sys-whonix).
sudo cat /var/run/tor/log | grep -i permissive
If a user is affected, a warning similar to the following will appear.
Aug 03 17:36:33.000 [warn] Permissions on directory /var/run/tor are too permissive.
Currently there is only one workaround, which needs to be manually applied after every reboot.
Log Analysis[edit]
Introduction[edit]
Analysis of Tor's log can be useful if connectivity issues emerge.
Open Tor Log[edit]
Users can inspect two logs:
- The persistent Tor log: /var/log/tor/log; and/or
- The Tor log since last boot: /var/run/tor/log [2]
Open /var/run/tor/log in an editor with root rights.
If you are using a graphical Whonix or Qubes-Whonix, run.
If you are using a terminal-only Whonix, run.
Watch Tor Log[edit]
Users can also watch Tor's log as it is written.
This command is especially useful when Tor is reloaded or restarted simultaneously in another terminal window.
To reload Tor, run the following command.
To restart Tor, run the following command.
Non-Issues[edit]
| message / question | answer |
|---|---|
| Am I compromised? Does Tor's log report leaks? | Tor's output is an ineffective tool for discovering serious issues such as a compromise or leaks. |
| [WARN] Socks version 71 not recognized. (Tor is not an http proxy.) |
This warning is caused by whonixcheck, specifically the function check_tor_socks_port_reachability which checks if a Tor SocksPort is reachable by trying to fetch it using curl. [3] No warnings appear if the function works correctly. |
| [NOTICE] You configured a non-loopback address '10.152.152.10:9179' for SocksPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted. [1 duplicate hidden] This notice may reference other port numbers, or the DnsPort or TransPort. | This notice is not a concern because Tor really listens on that IP/port - it is the internal network interface for Whonix-Gateway (sys-whonix) that is only available to Whonix-Workstations because Whonix-Gateway (sys-whonix) is firewalled. See /usr/bin/whonix_firewall or the Whonix source code for further information.
|
| [NOTICE] New control connection opened. [2 duplicates hidden] A higher number of duplicate messages may also appear. | This notice is not a concern because it is caused by whonixcheck's Tor Bootstrap Status Test, which uses Tor's ControlPort or CPFP. |
See Also[edit]
- Why does Whonix use Tor?
- Why is Tor slow?
- Censorship Circumvention - Tor Bridge Mode, using (private) (obfuscated) bridges
- Hide the fact that you are using Tor/Whonix
- Controlling Tor
- Hosting Tor Onion Services, ANY, Hidden Webserver
- Comparison of Tor, Proxies, CGI proxies, Proxy Chains and VPN Services
Advanced Topics[edit]
Entry Guards[edit]
Introduction[edit]
What are Tor Entry Guards? If this is an unfamiliar term, please press on Expand on the right.
Current practical, low-latency, anonymity designs like Tor fail when the attacker can see both ends of the communication channel. For example, suppose the attacker controls or watches the Tor relay a user chooses to enter the network, and also controls or watches the website visited. In this case, the research community is unaware of any practical, low-latency design that can reliably prevent the attacker from correlating volume and timing information on both ends.
Mitigating this threat requires consideration of the Tor network topology. Suppose the attacker controls, or can observe, C relays from a pool of N total relays. If a user selects a new entry and exit relay each time the Tor network is used, the attacker can correlate all traffic sent with a probability of (c/n)2. For most users, profiling is as hazardous as being traced all the time. Simply put, users want to repeat activities without the attacker noticing, but being noticed once by the attacker is as detrimental as being noticed more frequently. [...]
The solution to this problem is "entry guards". Each Tor client selects a few relays at random to use as entry points, and only uses those relays for the first hop. If those relays are not controlled or observed, the attacker can't use end-to-end techniques and the user is secure. If those relays are observed or controlled by the attacker, then they see a larger fraction of the user's traffic — but still the user is no more profiled than before. Thus, entry guards increase the user's chance of avoiding profiling (on the order of (n-c)/n), compared to the former case.
You can read more at An Analysis of the Degradation of Anonymous Protocols, Defending Anonymous Communication Against Passive Logging Attacks, and especially Locating Hidden Servers.
Restricting entry nodes may also help to defend against attackers who want to run a few Tor nodes and easily enumerate all of the Tor user IP addresses. [4] However, this feature won't become really useful until Tor moves to a "directory guard" design as well.
Source and License, see footnote: [5]
Many well known enhanced anonymity designs such as Tor, Whonix, and the Tor Browser Bundle (TBB) use persistent Tor guards. This decision is attributable to community-based research which demonstrates that persistent Tor entry guards benefit security and lower the probability of an adversary profiling a user.[6]
| Note: Guard fingerprinting techniques are similar to methods that track users via MAC addresses. If this is a realistic threat, then MAC address randomization is also recommended. |
In general, users should not interfere with Tor guard persistence or the natural rotation of entry guards every few months. At the time of writing, the Tor client selects one guard node, but previously used a three-guard design. Guards have a primary lifetime of 120 days.[7] [8] [9]
| Warning: In some situations it is safer to not use the usual guard relay! |
Guard Fingerprinting[edit]
While natural guard rotation is recommended, there are some corner cases in which an adversary could fingerprint the entry guards [10] and de-anonymize a user. For instance:
- The same entry guards are used across various physical locations and access points.
- The same entry guards are used after permanently moving to a different physical location.
Consider the following scenario. A user connects to Tor via a laptop at their home address. Soon afterwards, the same user attends a prominent event or protest in a nearby city. At that location, the user decides to anonymously blog about what transpired using the same laptop. This is problematic for anonymity, as the Tor client is using the same entry guard normally correlated with the user’s home address.
Network adversaries who are monitoring traffic have a high degree of certainty that the “anonymous” posts from the city location are related to the same person who connected to that specific guard relay at home. The relative uncommonness of Tor usage exacerbates the potential for de-anonymization.
There are several ways to mitigate the risk of guard fingerprinting across different physical locations. In most cases, the original entry guards can also be re-established after returning home:
- Configure Tor to use Alternate Bridges.
- If moving to a new location permanently, create Fresh Tor Entry Guards by Regenerating the Tor State File.
Forum discussion:
https://forums.whonix.org/t/persistent-tor-entry-guard-relays-can-make-you-trackable-across-different-physical-locations/2090
Manual Rotation of Tor Guards[edit]
Security and Performance Related Issues[edit]
Users may be tempted to create a new Whonix-Gateway (sys-whonix) in the following circumstances:
- Bootstrapping is slow or regularly fails.
- Tor logs show warnings suggesting evidence of route manipulation attacks or other oddities.
- Logs reveal attempted attacks on Whonix or Tor processes, for example in AppArmor logs.
- Current Tor performance is very slow or unreliable due to collapsing circuits or other factors.
- The user is concerned about the amount of Tor data that could be revealed if the Whonix-Gateway is infected, particularly after a long period of use.
Creating a new Whonix-Gateway or sys-whonix will likely lead to a new set of Tor entry guards, which is proven to degrade anonymity. Forcing the rotation of guards more often than Tor’s default is dangerous for several reasons:
- It increases the likelihood of a compromised or malicious Tor guard being selected. This increases the chance of a successful correlation attack if the adversary runs Tor exit relays in the network.
- The user is more likely to traverse a given set of Internet infrastructure links that are under the adversary's control, such as Autonomous Systems (ASes) or Internet Exchange Points (IXPs).
- Every change of Tor guards acts like a fingerprinting mechanism, since other users are less likely to pick the same set. If the adversary is able to enumerate a user's Tor guards, and later observes someone with the same set, the chance is high the two observations stem from the same person.
For these reasons the Tor Project changed its design in 2014 to have a solitary primary guard node, and increased the set period for guard rotation. Users should also not discount the possibility that an adversary might purposefully cause poor Tor throughput, in the hope Tor guards are manually changed:
We should also consider whether an adversary can *induce* congestion or resource exhaustion to cause a target user to switch away from her guard. Such an attack could work very nicely coupled with the guard enumeration attacks discussed above.
In one sense, slow Tor entry guards should be welcomed - “honeypot” operators on the Tor network are unlikely to have constrained bandwidth which might chase away intended targets.
| Warning: Users considering using disposable Whonix-Gateway ProxyVMs in Qubes R4 are warned that this technique severely degrades anonymity; new Tor guards are created during each distinct Whonix session. |
If users feel compelled in their circumstances to proceed despite the anonymity risks, then it may be safer to first try:
- One of the fallback primary entry guards.
- A configured bridge.
- Chaining other tunnels with Tor.
- Creating a fresh Whonix-Gateway (
sys-whonix), and copying across the Tor state file.
The safest decision is to persist with poor performance and wait for normal guard rotation.
Mitigate the Threat of Guard Fingerprinting[edit]
If guard fingerprinting across different locations is a concern, there are several ways to mitigate this threat. Viable options include: bridges, temporarily rotating guards, or cloning Whonix-Gateway (sys-whonix) with new guards.
| Note: Weigh the fingerprinting risks outlined in the previous section before proceeding. In most cases the decision to not rotate guards (even temporarily) is the correct one. |
Clone Whonix-Gateway (sys-whonix) with New Entry Guards[edit]
It is possible to clone the current Whonix-Gateway (sys-whonix) VM and regenerate the Tor state file. Once the VM is cloned, it is important that the original is not unintentionally used for any anonymous activities. To nullify this threat, consider disabling networking in the original Whonix-Gateway until returning home.
Warning: Users should not clone the Whonix-Gateway (sys-whonix) with new guards at the home address. If the Tor client connects through the home network, the new guards might be correlated to the home address. |
Create a clone of the Whonix-Gateway (sys-whonix) and name it Whonix-Gateway-temp VM (sys-whonix-temp VM) .
- Virtualbox: follow these instructions to create a VM snapshot.
- Qubes-Whonix:
Right-click on sys-whonix->Clone VM
- Regenerate the Tor State File.
Regenerate the Tor State After Saving the Tor State Folder[edit]
| Non-Qubes-Whonix only! |
Prior to arriving at the remote location, the Whonix-Gateway Tor state folder is moved to the $HOME directory, and the Tor state file is regenerated.
1. In Whonix-Gateway konsole, stop Tor.
2. In Whonix-Gateway konsole, remove the temporary Tor state folder.
3. In Whonix-Gateway konsole, restore the Tor state folder.
4. In Whonix-Gateway konsole, restart Tor.
Before returning home, the Tor state folder is restored to its original settings.
1. In Whonix-Gateway konsole, Stop Tor.
2. In Whonix-Gateway konsole, move the Tor state folder to the $HOME directory.
3. In Whonix-Gateway konsole, restart Tor.
Alternating Bridges[edit]
If bridges are already in use, alternate bridges are recommended for different locations. If bridges are not used, consideration should be given to using entry guards in your primary location and relying on alternate bridges in different locations.
Complete the following steps on Whonix-Gateway (Qubes-Whonix: sys-whonix).
1. Disable Tor using the whonix-setup-wizard (safest option).
Start the whonix-setup-wizard.
If you are using Qubes-Whonix, complete the following steps.
Qubes App Launcher (blue/grey "Q") -> Whonix-Gateway ProxyVM (commonly named 'sys-whonix') -> Whonix Setup
If you are using a graphical Whonix-Gateway, complete the following steps.
Start Menu -> Applications -> System -> Whonix Setup Wizard
If you are using a terminal-only Whonix-Gateway, complete the following steps.
Choose the Disable Tor option. Press next.
2. Configure Tor to use bridges. Refer to the Bridges documentation.
3. Enable Tor using whonixsetup / whonix-setup-wizard at the new location.
4. Before leaving this location, disable Tor. If traveling to a different area, add a different bridge address. To revert to the usual guard nodes used at home, remove the torrc bridge settings before enabling the network, or rollback to a VM snapshot created at home.
Copy Tor Configuration files and Settings to Another sys-whonix Instance[edit]
| Qubes-Whonix only! |
| Warning: Users are strongly encouraged to follow the instructions as they are written to avoid unforeseen consequences.[12] |
On occasion, Qubes-Whonix users may want to copy the Tor state along with custom configuration options from an existing sys-whonix ProxyVM to another sys-whonix instance. For example, this is useful for testing later Whonix releases without aiding deanonymization attempts by advanced adversaries, [13] or creating an identical backup that does not share any other persistent data, except for Tor state and custom torrc options.
Copy Tor State Files to Another sys-whonix Instance[edit]
The following instructions copy the Tor state from sys-whonix-old to sys-whonix-new.
1. In sys-whonix-new, stop Tor
2. In sys-whonix-new, remove the Tor state file.
Warning: Care is required when removing files so extra spaces are not added to the file path! As an example, if a space is accidentally placed before the asterisk in the command to remove the Tor state file, the removal of the / (root directory) and all system data would be the unfortunate consequence. |
3. In sys-whonix-old, stop Tor
4. In sys-whonix-old, copy the Tor state file across to sys-whonix-new
If the following error appears, it can be safely ignored (hit "OK" when prompted).
qfile-agent: Fatal error: stat “VM” (error type: No such file or directory)
5. In sys-whonix-new, list the QubesIncoming directory to ensure the Tor state file was copied over successfully
The output should include the files below.
cached-certs cached-microdescs lockcached-microdesc-consensus cached-microdescs.new state
6. In sys-whonix-new, move the newly copied Tor state file to /var/lib/tor
7. In sys-whonix-new, change ownership of all files in the Tor state folder to debian-tor
8. In sys-whonix-new, start Tor
9. In sys-whonix-new, run whonixcheck to verify Tor is functioning properly[14]
Copy Tor Configuration Options (torrc) to Another sys-whonix[edit]
Note: Users may also migrate Whonix 13 torrc options to Whonix 14 based sys-whonix instances. To do this users must revise the instructions to use /usr/local/etc/torrc.d/50_user.conf as the destination for the torrc options in place of /etc/tor/torrc[15]
sys-whonix VMs, use /usr/local/etc/torrc.d/50_user.conf as both the source and destination file for torrc options.[16] |
Note: For Whonix 14 and later releases, all user unique Tor configurations (torrc) options should be stored in /usr/local/etc/torrc.d/50_user.conf and not anywhere else. |
The following instructions copy the custom Tor configuration options (torrc) from sys-whonix-old to sys-whonix-new.
1. In sys-whonix-old, copy the torrc options across to sys-whonix-new
If the following error appears, it can be safely ignored (hit "OK" when prompted).
qfile-agent: Fatal error: stat “VM” (error type: No such file or directory)
2. In sys-whonix-new, print the QubesIncoming directory to ensure the torrc options were copied over successfully
3. In sys-whonix-new, move the torrc options from the QubesIncoming directory to the torrc file
4. In sys-whonix-new, change ownership of the Tor configuration file
5. In sys-whonix-new, restart Tor so the newly copied torrc options take affect
6. In sys-whonix-new, run whonixcheck to verify Tor is functioning properly.[17]
Fresh Tor Entry Guards by Regenerating the Tor State File[edit]
| The action is inadvisable unless the user is aware of the consequences; see Introduction. |
The following instructions manually change a user's Tor entry guards. One use case for this action is before a user permanently relocates to a new area.
Complete the following steps on Whonix-Gateway (Qubes-Whonix: sys-whonix).
1. Disable Tor using the whonix-setup-wizard (safest option).
Start the whonix-setup-wizard.
If you are using Qubes-Whonix, complete the following steps.
Qubes App Launcher (blue/grey "Q") -> Whonix-Gateway ProxyVM (commonly named 'sys-whonix') -> Whonix Setup
If you are using a graphical Whonix-Gateway, complete the following steps.
Start Menu -> Applications -> System -> Whonix Setup Wizard
If you are using a terminal-only Whonix-Gateway, complete the following steps.
Choose the Disable Tor option. Press next.
2. Delete Tor's state file.
3. Enable Tor using whonixsetup / whonix-setup-wizard at the new location.
Configure Non-Persistent Entry Guards[edit]
Some users may consider configuring non-persistent entry guards so they constantly change. In almost all cases this is inadvisable, because persistent entry guards are a critical security feature as explained in the introduction. A far more secure alternative is Alternating Bridges, although this requires a considerable time investment.
To proceed in spite of the warning, press on expand on the right.
Complete these steps in Whonix-Gateway (Qubes-Whonix: sys-whonix).
1. If using Whonix 12 or earlier, adjust whonixcheck settings.
Open /etc/whonix.d/50_user.conf in an editor with root rights.
If you are using a graphical Whonix or Qubes-Whonix, run.
If you are using a terminal-only Whonix, run.
Add.
Save.
2. Disable Tor using the whonix-setup-wizard (safest option).
Start the whonix-setup-wizard.
If you are using Qubes-Whonix, complete the following steps.
Qubes App Launcher (blue/grey "Q") -> Whonix-Gateway ProxyVM (commonly named 'sys-whonix') -> Whonix Setup
If you are using a graphical Whonix-Gateway, complete the following steps.
Start Menu -> Applications -> System -> Whonix Setup Wizard
If you are using a terminal-only Whonix-Gateway, complete the following steps.
Choose the Disable Tor option. Press next.
3. Modify Tor settings.
| For Whonix 14 and later releases, all unique Tor configurations should be stored in /usr/local/etc/torrc.d/50_user.conf. Users should not edit /etc/tor/torrc directly. |
Open /etc/tor/torrc.
If you are using Qubes-Whonix, complete the following steps.
Qubes App Launcher (blue/grey "Q") -> Whonix-Gateway ProxyVM (commonly named sys-whonix) -> Tor User Config (Torrc)
If you are using a graphical Whonix-Gateway, complete the following steps.
Start Menu -> Applications -> Settings -> /etc/tor/torrc
If you are using a terminal-only Whonix-Gateway, complete the following steps.
Add.
Save.
4. Enable Tor using whonixsetup / whonix-setup-wizard at the new location.
5. Before leaving this location, disable Tor and repeat the above steps if traveling to a different area. To revert to the usual guard nodes at home, remove the torrc setting before enabling the network, or rollback to a VM snapshot that was created there.
Notes[edit]
- The proposed Tails solutions towards AdvGoalTracking have disadvantages [18] [19] and are not suitable options for Whonix. The reason is Whonix does not connect directly to a user's internet LAN, so trying to remember a network based on its SSID will not work. Unlike wireless access points, physical or virtual wired networks lack SSIDs and cannot be "remembered" that way.
- Even if it were possible, it is best to avoid letting adversaries influence guard changes in any way. Spoofing MAC addresses or SSIDs would trigger the use of the alternate entry guard recorded for another "location profile". Global networks also have generic characteristics that cannot be differentiated from the point of view of a connecting device, resulting in the same guards being used on different networks.
- Developers/Auditors-only: The development discussion related to this documentation chapter: research non-persistent entry guards.
Blacklist Certain Onion Services from Connecting[edit]
| This procedure is experimental. Testers only. |
| For Whonix 14 and later releases, all unique Tor configurations should be stored in /usr/local/etc/torrc.d/50_user.conf. Users should not edit /etc/tor/torrc directly. |
Open /etc/tor/torrc.
If you are using Qubes-Whonix, complete the following steps.
Qubes App Launcher (blue/grey "Q") -> Whonix-Gateway ProxyVM (commonly named sys-whonix) -> Tor User Config (Torrc)
If you are using a graphical Whonix-Gateway, complete the following steps.
Start Menu -> Applications -> Settings -> /etc/tor/torrc
If you are using a terminal-only Whonix-Gateway, complete the following steps.
The following is an example onion service that is added to /etc/tor/torrc. Replace bbbbbb6qtmqg65g6.onion with the actual onion service that should be blacklisted.
Reload Tor.
After editing /etc/tor/torrc, Tor must be reloaded for changes to take effect.
Note: If Tor does not connect after completing all these steps, then a user mistake is the most likely explanation. Recheck /etc/tor/torrc and repeat the steps outlined in the sections above. If Tor then connects successfully, all the necessary changes have been made.
If you are using Qubes-Whonix, complete the following steps.
Qubes App Launcher (blue/grey "Q") -> Whonix-Gateway ProxyVM (commonly named 'sys-whonix') -> Reload Tor
If you are using a graphical Whonix-Gateway, complete the following steps.
Start Menu -> Applications -> Settings -> Reload Tor
If you are using a terminal-only Whonix-Gateway, press on Expand on the right.
Complete the following steps.
Reload Tor.
Check Tor's daemon status.
It should include a a message saying.
Active: active (running) since ...
In case of issues, try the following debugging steps.
Check Tor's config.
The output should be similar to the following.
Sep 17 17:40:41.416 [notice] Read configuration file "/etc/tor/torrc". Configuration was valid
Additional SocksPorts[edit]
Adding additional Tor SocksPorts to /etc/tor/torrc is non-intuitive. [20]
As noted in the Tor man page (man tor):
By default, an option on the command line overrides an option found in the configuration file, and an option in a configuration file overrides one in the defaults file.
This rule is simple for options that take a single value, but it can become complicated for options that are allowed to occur more than once: if you specify four SOCKSPorts in your configuration file, and one more SOCKSPort on the command line, the option on the command line will replace all of the SOCKSPorts in the configuration file. If this is not what you want, prefix the option name with a plus sign, and it will be appended to the previous set of options instead.
Nick Mathewson from The Tor Project has also noted: [21]
So to make sure that the SocksPort in the torrc does what you want, write it as
+SocksPort.
After adding custom ports, a user would also have to edit the Whonix firewall unless they were lucky. For example, various custom ports for such use cases have already been added. Those are documented here.
UDP[edit]
| The Tor software does not yet support UDP, [22] although Tor provides a DnsPort. If UDP is urgently required in Whonix, a limited workaround is provided. For the most secure method, see Tunnel UDP over Tor. |
Reload Tor[edit]
Reload Tor.
After editing /etc/tor/torrc, Tor must be reloaded for changes to take effect.
Note: If Tor does not connect after completing all these steps, then a user mistake is the most likely explanation. Recheck /etc/tor/torrc and repeat the steps outlined in the sections above. If Tor then connects successfully, all the necessary changes have been made.
If you are using Qubes-Whonix, complete the following steps.
Qubes App Launcher (blue/grey "Q") -> Whonix-Gateway ProxyVM (commonly named 'sys-whonix') -> Reload Tor
If you are using a graphical Whonix-Gateway, complete the following steps.
Start Menu -> Applications -> Settings -> Reload Tor
If you are using a terminal-only Whonix-Gateway, press on Expand on the right.
Complete the following steps.
Reload Tor.
Check Tor's daemon status.
It should include a a message saying.
Active: active (running) since ...
In case of issues, try the following debugging steps.
Check Tor's config.
The output should be similar to the following.
Sep 17 17:40:41.416 [notice] Read configuration file "/etc/tor/torrc". Configuration was valid
Restart Tor[edit]
Restart Tor.
If you are using Qubes-Whonix, complete the following steps.
Qubes App Launcher (blue/grey "Q") -> Whonix-Gateway ProxyVM (commonly named 'sys-whonix') -> Restart Tor
If you are using a graphical Whonix-Gateway, complete the following steps.
Start Menu -> Applications -> Settings -> Restart Tor
If you are using a terminal-only Whonix-Gateway, press on Expand on the right.
Complete the following steps.
Restart Tor.
Check Tor's daemon status.
It should include a a message saying.
Active: active (running) since ...
In case of issues, try the following debugging steps.
Check Tor's config.
The output should be similar to the following.
Sep 17 17:40:41.416 [notice] Read configuration file "/etc/tor/torrc". Configuration was valid
Disable Tor[edit]
Disable Tor using the whonix-setup-wizard (safest option).
Start the whonix-setup-wizard.
If you are using Qubes-Whonix, complete the following steps.
Qubes App Launcher (blue/grey "Q") -> Whonix-Gateway ProxyVM (commonly named 'sys-whonix') -> Whonix Setup
If you are using a graphical Whonix-Gateway, complete the following steps.
Start Menu -> Applications -> System -> Whonix Setup Wizard
If you are using a terminal-only Whonix-Gateway, complete the following steps.
Choose the Disable Tor option. Press next.
Footnotes / References[edit]
- ↑ https://trac.torproject.org/projects/tor/ticket/19824
- ↑
/var/run/tor/log is a Tor configuration file specific to Whonix and an alternative to /var/log/tor/log. The former only contains Tor's output since Whonix-Gateway (
sys-whonix) last booted. The latter is a permanent log that persists across reboots. The former has a small usability advantage because it is shorter and should therefore contain more relevant information. - ↑
- ↑ Even though the attacker can't discover the user's destinations in the network, they still might target a list of known Tor users.
- ↑
Source:
torproject.org What are Entry Guards? (w)
license (w):
Content on this site is Copyright The Tor Project, Inc.. Reproduction of content is permitted under a Creative Commons Attribution 3.0 United States License (w). All use under such license must be accompanied by a clear and prominent attribution that identifies The Tor Project, Inc. as the owner and originator of such content. The Tor Project Inc. reserves the right to change licenses and permissions at any time in its sole discretion. - ↑ The risk of guard fingerprinting is less severe now that upstream (The Tor Project) has changed its guard parameters to decrease the de-anonymization risk.
- ↑ Prop 291 indicates a 3.5 month guard rotation.
- ↑ The Tor Project is currently considering shifting to two guards per client for better anonymity, instead of having one primary guard in use.
- ↑ https://github.com/torproject/torspec/blob/master/proposals/291-two-guard-nodes.txt
- ↑ The entropy associated with one, two or three guards is 9, 17 and 25 bits, respectively.
- ↑ As concluded in ticket research non-persistent Tor directory guards, these are covered by the following instructions.
- ↑ If users were to use an alternate command to remove the Tor state folder, this could result in broken file persistence across reboots. This relates to the Qubes-Whonix design, which uses
bind-dirsfile persistence for the Tor folder and other select directories. At the very least, users would need to mount, then unmount the Tor folder in the same way asbind-dirsdoes. This would likely be a complicated and time consuming task. - ↑ As the same Tor entry guard is used.
- ↑ If Tor fails to start, users should verify the Tor folder has the proper file permissions with the following command
sudo ls -l /var/lib/tor - ↑ When users reach step 3 in the instructions,
move the torrc options from the QubesIncoming directory to the torrc file
sudo mv ~/QubesIncoming/sys-whonix-old/torrc /usr/local/etc/torrc.d/50_user.conf - ↑
Users should revise instructions as follows
Step 1qvm-copy /usr/local/etc/torrc.d/50_user.conf sys-whonix-new
Step 2cat ~/QubesIncoming/sys-whonix-old/50_user.conf
Step 3sudo mv ~/QubesIncoming/sys-whonix-old/50_user.conf /usr/local/etc/torrc.d/50_user.conf
Step 4sudo chown -R root:root /usr/local/etc/torrc.d - ↑ If Tor is not running after restart, users can verify the newly migrated torrc options are valid with this command
sudo -u debian-tor tor --verify-configThe output should be similar to the following.
Sep 17 17:40:41.416 [notice] Read configuration file "/etc/tor/torrc". Configuration was valid - ↑ https://tails.boum.org/blueprint/persistent_Tor_state/
- ↑ https://blog.torproject.org/blog/tor-weekly-news-%E2%80%94-june-17th-2015#A_persistent_Tor_state_for_Tails
- ↑ https://trac.torproject.org/projects/tor/ticket/15261
- ↑ https://trac.torproject.org/projects/tor/ticket/15261#comment:1
- ↑ https://trac.torproject.org/projects/tor/ticket/7830
We are looking for video production specialists to help create demonstration, promotional and conceptual videos or tutorials.
This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! See Conditions for Contributions to Whonix, then Edit! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation.
Whonix is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Libre Software license as Whonix itself. (Why?)