These are my proposed changes for Tor#Entry_Guards
These edit go across two templates
https://whonix.org/wiki/Tor#Entry_Guards
https://whonix.org/wiki/Template:Persistent_Tor_Entry_Guards_Introduction
Please let me know if any changes are needed
Introduction
Note: Text Box taken from Tor project describing entry guards is not posted. It will have one minor edit as per Patrick.
Many well known enhanced anonymity designs such as Tor, Whonix, Tor Browser Bundles (TBB) all use persistent guards. This is attributable to community based research initiatives which have shown the use of persistent Tor entry guards benefit security and lowers the probability of an adversary profiling a user. For this reason, allowing the Tor client to rotate entry guards through natural churn is the correct choice for most users. At the time this chapter was written, the Tor client selects three guard nodes, but defers to a primary guard whenever possible. Guards have a primary lifetime of 120 days.
Warning: In some situations it is safer to not use the usual guard relay!
Guard Fingerprinting
While users are encouraged to allow guard rotation through natural churn, there are some corner cases in which an adversary could fingerprint the entry guards and de-anonymize a user. This maybe be possible if:
Consider the following scenario. While at their home address a user connects to Tor using a laptop. Soon afterwards, that 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. The fact that the Tor client is using the same entry guard normally correlated with the user’s home address is problematic. Network adversaries would have a high certainty that the “anonymous” posts from the city location are related to the same person who connected to that specific guard relay from their home. The relative uncommonness of Tor usage exacerbates the potential for de-anonymization.
Several options are available to mitigate the risk of guard fingerprinting across various physical locations. These options allow the original entry guards are used when back at the home address.
-
Clone Whonix-Gateway (sys-whonix) with New Entry Guards
-
Regenerate Tor State File after Saving Current Tor State
-
Configure Tor to use Alternate Bridges
-
If moving to a new location permanently, create Fresh Tor Entry Guards by Regenerating the Tor State File
The risk of this attack is less severe now that upstream (The Tor Project) has changed its guard parameters to decrease the de-anonymization risk.
This adversary technique is similar to tracking users via MAC addresses. Therefore, for users facing this threat in their personal circumstances, MAC address randomization is also recommended.
Forum discussion:
[…]persistent-tor-entry-guard-relays-can-make-you-trackable-across-different-physical-locations/2090
Manual Rotation of Tor Guards
Security and Performance Related Issues
On occasion, users may be tempted to create a new Whonix-Gateway : sys-whonix on account of:
- 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.
- A change in the Tor guard selection which has resulted in poor throughput due to capacity issues.
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. Voluntary guard rotation via a new Whonix-Gateway is more dangerous than allowing “natural churn” as chosen by the Tor application for several reasons:
- It increases the likelihood of a compromised or malicious Tor guard being selected, leading to a corresponding rise in 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 has changed its design and reduced the number of primary guard nodes to 3, and increased the set period for guard rotation. The user should also contemplate the possibility their current poor Tor performance is an attempt by an advanced adversary to cause frustration, leading to a manual change in Tor guards:
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, users should welcome slow entry guards, since “honeypot” operators on the Tor network are unlikely to have constrained bandwidth which might chase away intended targets. This thinking aligns with intelligence disclosures which deem all Tor users to be persons of interest to state-level adversaries.
Warning: Users considering using disposable Whonix-Gateway ProxyVMs in Qubes R4 are warned that this technique poses an even greater anonymity risk than described above; new Tor guards are created during each distinct Whonix session.
Under certain circumstances, users will feel compelled to proceed despite the anonymity risks. In this instance, it may be safer to first try:
- One of the fallback primary entry guards.
- A configured bridge.
- Possibly combine tunnels with Tor.
- Creating a fresh Whonix-Gateway (sys-whonix), and copying across the Tor state file.
The user can also persist with poor performance and wait for normal guard rotation. Users should note that regenerating the Tor state file poses the same anonymity risks as outlined in this section.
Mitigate the Threat of Guard Fingerprinting
If guard fingerprinting over different locations is a concern. There are several options that may be used to mitigate this threat. These option include using bridges, temporarily rotating guards or cloning Whonix-Gateway with new guards. However, the decision to rotate entry guards should not be taken lightly even if on a temporary basis. Users should weigh the risk posed by rotating guards as mentioned in the previous chapter against the threat posed by fingerprinting. In some cases, the decision to not rotate entry guards may be the better choice. In any event, this decision should be made on a case by case basis considering all the benefits and risks for each possible choice.
Clone Whonix-Gateway (sys-whonix) with New Entry Guards
Users can clone a current Whonix-Gateway (sys-whonix) VM and regenerate the Tor state file. Once the VM is cloned, care must be taken to ensure the original is not unintentionally used for the anonymous activities. It light of this, users may wish to disable networking in the original Whonix-Gateway until back at the home address.
Warning: Users should not clone the Whonix-Gateway (sys-whonix) with new guards at the home address. If the Tor client connected through the home network, the new guards could 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 Tor State After Saving the Tor State Folder
Non-Qubes-Whonix only!
Prior to arriving at the remote location. The user moves the Whonix-Gateway Tor state folder to the $HOME directory then regenerates the Tor state file.
1. In Whonix-Gateway konsole, stop Tor.
sudo systemctl stop tor@default
2. In Whonix-Gateway konsole, remove the temporary Tor state folder
sudo rm -r /var/lib/tor
3. Restore the Tor state folder
sudo mv ~/tor /var/lib
4. Restart Tor
sudo systemctl restart tor@default
Prior to arriving back at the home location, the Tor state folder is restored back to its original settings.
1. In Whonix-Gateway konsole, Stop Tor
sudo systemctl stop tor@default
2. In Whonix-Gateway konsole, move the Tor state folder to the $HOME directory
sudo mv /var/lib/tor ~/
3. In Whonix-Gateway konsole, restart Tor
sudo systemctl restart tor@default
Alternating Bridges
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-Whonixsys-whonix.
1. Disable_Tor
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 and add a different bridge address if traveling to a different area. 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
No changes in this chapter. Next chapter has edits in steps 1 and 5
Configure Non-Persistent Entry Guards
# These instructions work to configure sys-whonix to use non-persistent entry guard but some functionality changes.
Example:
[ user@host:~]$ arm
“permission denied”
[ user@host:~]$ sudo arm
arm starts and is functional
## Also instructions state “For Whonix 12 or earlier”. Am I missing something?
1. If using Whonix 12 or earlier, adjust whonixcheck settings.
2. […]
3. […]
4. […]
5. Before leaving this location, shutdown the Whonix-Gateway (sys-whonix) VM. When the new location is reached, new entry guards will be used when the VM is started. 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 previously created.
I’m happy to do new content edits in combo with clean up work, edit others work etc. but I’m focusing on cleanup work currently.
