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 [https://www.freehaven.net/anonbib/#wright02 An Analysis of the Degradation of Anonymous Protocols], [https://www.freehaven.net/anonbib/#wright03 Defending Anonymous Communication Against Passive Logging Attacks], and especially [https://www.freehaven.net/anonbib/#hs-attack06 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. Even though the attacker can't discover the user's destinations in the network, they still might target a list of known Tor users. However, this feature won't become really useful until Tor moves to a "directory guard" design as well.
Source and License, see footnote: Source:{{project_name_gateway_vm}}) will ''likely'' lead to a new set of Tor entry guards, which is [https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters proven to degrade anonymity].
{{mbox
| image = [[File:Ambox_warning_pn.svg.png|40px]]
| text ='''Warning:''' Users considering using disposable {{project_name_gateway_short}} ProxyVMs in Qubes R4 are [[Qubes/Disposables#Warnings|warned]] that this technique severely degrades anonymity; new Tor guards are created during each distinct {{project_name_short}} session.
}}
== Anonymity and Performance-related Issues ==
Users may be tempted to create a new {{project_name_gateway_short}} ({{project_name_gateway_vm}}) in the following circumstances:
* Bootstrapping is slow or regularly fails.
* Tor logs show warnings suggestive of route manipulation attacks or other oddities.
* System logs reveal attempted attacks on {{project_name_short}} 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 {{project_name_gateway_short}} is infected, particularly after a long period of use.
== Manual Guard Rotation Threats ==
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 raises the chance of a successful [https://securityaffairs.co/wordpress/17489/intelligence/traf%EF%AC%81c-correlation-vs-anonymity-on-tor.html correlation attack] if the adversary runs Tor exit relays in the network.
* The user is more likely to traverse a [https://www.freehaven.net/anonbib/#feamster:wpes2004 given] [https://www.freehaven.net/anonbib/#DBLP:conf:ccs:EdmanS09 set] of [https://www.freehaven.net/anonbib/#ndss13-relay-selection Internet infrastructure links] that are under the adversary's control, such as [https://web.mit.edu/6.033/www/papers/InterdomainRouting.pdf Autonomous Systems (ASes)] or [https://www.itu.int/en/wtpf-13/Documents/backgrounder-wtpf-13-ixps-en.pdf Internet Exchange Points (IXPs)].
* Every Tor guard change 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 design changed in 2014 to establish a solitary primary guard node, while also increasing the set period for guard rotation. Also, do not discount the possibility that an adversary might purposefully cause poor Tor throughput, in the hope Tor guards are manually changed: https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters
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. == Recommendations == 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 [[Bridges|bridge]]. * Chaining other [[Tunnels/Introduction|tunnels]] with Tor. * Creating a fresh {{project_name_gateway_short}} (
{{project_name_gateway_vm}}) and [[#Copy_Tor_Configuration_files_and_Settings_to_Another_{{project_name_gateway_vm}}_Instance|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 =
Note: Weigh the fingerprinting risks outlined earlier before proceeding. In most cases the decision to not rotate guards (even temporarily) is the correct one.
If guard fingerprinting across different locations is a legitimate concern, there are several ways to mitigate the threat. Viable options include: bridges, temporarily rotating guards or cloning {{project_name_gateway_short}} ({{project_name_gateway_vm}}) with new guards.
== Clone {{project_name_gateway_short}} ({{project_name_gateway_vm}}) with New Entry Guards ==
{{mbox
| image = [[File:Ambox_warning_pn.svg.png|40px]]
| text ='''Warning:''' Do not clone the {{project_name_gateway_short}} ({{project_name_gateway_vm}}) with new guards at your home address. If the Tor client connects through the home network, the new guards might be correlated to the home address.
}}
It is possible to clone the current {{project_name_gateway_short}} ({{project_name_gateway_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 negate this threat, disable networking in the original {{project_name_gateway_short}} until returning home.
Create a {{project_name_gateway_short}} ({{project_name_gateway_vm}}) clone and name it {{project_name_gateway_short}}-temp ({{project_name_gateway_vm}}-temp):
# VirtualBox: follow [https://dirkstrauss.com/clone-virtualbox-vm/ these instructions] to create a VM snapshot. Right-click on {{project_name_gateway_vm}} → Clone qube
# [[#Fresh_Tor_Entry_Guards_by_Regenerating_the_Tor_State_File|Regenerate the Tor State File]].
== Regenerate the Tor State After Saving the Tor State Folder ==
{{mbox
| type = notice
| image = [[File:Ambox_notice.png|40px|alt=Info]]
| text = [[Non-Qubes-Whonix|{{non_q_project_name_short}}]] only.
}}
Before arriving at the remote location, the {{project_name_gateway_short}} Tor state folder is moved to the $HOME directory and the Tor state file is regenerated. Perform all the following steps in {{project_name_gateway_short}} konsole.
{{Box|text=
'''1.''' Stop Tor.
{{CodeSelect|code=
sudo systemctl stop tor@default
}}
'''2.''' Move the Tor state folder to the $HOME directory.
{{CodeSelect|code=
sudo mv /var/lib/tor ~/
}}
'''3.''' Restart Tor.
{{CodeSelect|code=
sudo systemctl restart tor@default
}}
}}
Before returning home, the Tor state folder is restored to its original settings.
{{Box|text=
'''1.''' Stop Tor.
{{CodeSelect|code=
sudo systemctl stop tor@default
}}
'''2.''' Remove the temporary Tor state folder.
{{CodeSelect|code=
sudo rm -r /var/lib/tor
}}
'''3.''' Restore the Tor state folder.
{{CodeSelect|code=
sudo mv ~/tor /var/lib
}}
'''4.''' Restart Tor.
{{CodeSelect|code=
sudo systemctl restart tor@default
}}
}}
== Alternating Bridges ==
If [[Bridges|Bridges]] are already configured, alternate bridges are recommended for different locations. If bridges are not being used, consider using entry guards in your primary location and relying on alternate bridges in different locations.
Wording clarification: There is no such thing as "Alternating-Bridges". It's not it's own word. It means "a bridge to alternate". As in "use different bridges".
Complete the following steps in {{project_name_gateway_short}} ({{project_name_gateway_vm}}).
{{Box|text=
'''1.''' {{Disable_Tor}}
'''2.''' Configure Tor to use bridges. Refer to the [[Bridges|Bridges]] documentation.
'''3.''' Enable Tor at the new location.
{{Enable_Tor}}
'''4.''' Before leaving this location, disable Tor. If traveling to a different area, add a different bridge address. To revert to the usual Tor guards 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 {{project_name_gateway_vm}} Instance ==
{{mbox
| type = notice
| image = [[File:Ambox_notice.png|40px|alt=Info]]
| text = [[Qubes|{{q_project_name_short}}]] only.
}}
{{mbox
| image = [[File:Ambox_warning_pn.svg.png|40px]]
| text ='''Warning:''' Carefully follow these instructions to avoid unforeseen consequences. If an alternative command is used to remove the Tor state folder, this can result in broken file persistence across reboots. This relates to the [[Qubes|{{q_project_name_short}}]] design, which uses bind-dirs file persistence for the Tor folder and other select directories. At the very least, users would need to mount and then unmount the Tor folder in the same way as bind-dirs does. This is likely a complicated and time-consuming task.
}}
In some circumstances [[Qubes|{{q_project_name_short}}]] users might want to copy the Tor state and custom configuration options from an existing {{project_name_gateway_vm}} ProxyVM to another {{project_name_gateway_vm}} instance. For example, this is useful for testing later {{project_name_short}} releases without aiding deanonymization attempts by advanced adversaries As the same Tor entry guard is used. or when 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 {{project_name_gateway_vm}} Instance ===
The following instructions copy the Tor state from {{project_name_gateway_vm}}-old to {{project_name_gateway_vm}}-new.
{{Box|text=
'''1.''' In {{project_name_gateway_vm}}-new, stop Tor.
{{CodeSelect|code=
sudo systemctl stop tor@default
}}
'''2.''' In {{project_name_gateway_vm}}-new, remove the Tor state file.
{{mbox
| image = [[File:Ambox_warning_pn.svg.png|40px]]
| text ='''Warning:''' When removing files take care that extra spaces are not added to the file path! For example, if a space is accidentally placed before the asterisk in the command to remove the Tor state file, the / (root directory) and all system data would be lost.
}}
{{CodeSelect|code=
sudo su
}}
{{CodeSelect|code=
sudo rm /var/lib/tor/*
}}
'''3.''' In {{project_name_gateway_vm}}-old, stop Tor.
{{CodeSelect|code=
sudo systemctl stop tor@default
}}
'''4.''' In {{project_name_gateway_vm}}-old, copy the Tor state file across to {{project_name_gateway_vm}}-new.
{{CodeSelect|code=
sudo qvm-copy /var/lib/tor {{project_name_gateway_vm}}-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
{{project_name_gateway_vm}}-new, list the QubesIncoming directory to ensure the Tor state file was copied over successfully.
{{CodeSelect|code=
ls ~/QubesIncoming/{{project_name_gateway_vm}}-old/tor
}}
The output should include the files below.
cached-certs cached-microdescs lock
cached-microdesc-consensus cached-microdescs.new state
'''6.''' In {{project_name_gateway_vm}}-new, move the newly copied Tor state file to ''/var/lib/tor''
{{CodeSelect|code=
sudo mv ~/QubesIncoming/{{project_name_gateway_vm}}-old/tor/* /var/lib/tor
}}
'''7.''' In {{project_name_gateway_vm}}-new, change ownership of all files in the Tor state folder to debian-tor
{{CodeSelect|code=
sudo chown -R debian-tor:debian-tor /var/lib/tor
}}
'''8.''' In {{project_name_gateway_vm}}-new, start Tor.
{{CodeSelect|code=
sudo systemctl start tor@default
}}
'''9.''' In {{project_name_gateway_vm}}-new, run [https://www.kicksecure.com/wiki/Systemcheck systemcheck] to verify Tor is functioning properly. If Tor fails to start, verify the Tor folder has the proper file permissions with the following command: sudo ls -l /var/lib/tor
{{CodeSelect|code=
whonixcheck
}}
}}
=== Copy Tor Configuration Options (torrc) to Another {{project_name_gateway_vm}} ===
These instructions copy custom Tor configuration options (torrc) from {{project_name_gateway_vm}}-old to {{project_name_gateway_vm}}-new.
{{Box|text=
'''1.''' In {{project_name_gateway_vm}}-old, copy the torrc options across to {{project_name_gateway_vm}}-new. Note: From {{project_name_short}} 14 onward, all unique Tor configurations (torrc) options must be stored in /usr/local/etc/torrc.d/50_user.conf and nowhere else.
{{CodeSelect|code=
qvm-copy /usr/local/etc/torrc.d/50_user.conf {{project_name_gateway_vm}}-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 {{project_name_gateway_vm}}-new, list the QubesIncoming directory to ensure the torrc options were copied over successfully.
{{CodeSelect|code=
cat ~/QubesIncoming/{{project_name_gateway_vm}}-old/50_user.conf
}}
'''3.''' In {{project_name_gateway_vm}}-new, move the 50_user.conf options from the QubesIncoming directory to the 50_user.conf file.
{{CodeSelect|code=
sudo mv ~/QubesIncoming/{{project_name_gateway_vm}}-old/50_user.conf /usr/local/etc/torrc.d/50_user.conf
}}
'''4.''' In {{project_name_gateway_vm}}-new, change ownership of the Tor configuration file.
{{CodeSelect|code=
sudo chown -R root:root /etc/tor
}}
'''5.''' In {{project_name_gateway_vm}}-new, restart Tor so the newly copied Tor config options take effect.
{{CodeSelect|code=
sudo systemctl restart tor@default
}}
'''6.''' In {{project_name_gateway_vm}}-new, run [https://www.kicksecure.com/wiki/Systemcheck systemcheck] to verify Tor is functioning properly.
If Tor is not running after restart, it is possible to verify the newly migrated torrc options are valid with the following command: anon-verify. The output should be similar to the following.
/===================================================================\ | Report Summary | \===================================================================/ No error detected in your Tor configuration.{{CodeSelect|code= systemcheck }} }} = Unsafe Guard Rotation Methods = == Fresh Tor Entry Guards by Regenerating the Tor State File == {{mbox | image = [[File:Ambox_warning_pn.svg.png|40px]] | text = This action is inadvisable unless the user is aware of the consequences; see [[#Introduction|Introduction]]. }} The following instructions manually change a user's Tor entry guards. One use case for this action is before permanently relocating to a new area. Potential [[Unsupported]] alternative. {{CodeSelect|code= tor-ctrl DROPGUARDS }} {{Box|text= Complete the following steps in {{project_name_gateway_short}} ([[Qubes|{{q_project_name_short}}]]:
{{project_name_gateway_vm}}).
'''1.''' {{Disable_Tor}}
'''2.''' Delete Tor's state file.
{{CodeSelect|code=
sudo rm /var/lib/tor/state
}}
'''3.''' Enable Tor at the new location.
{{Enable_Tor}}
}}
== Configure Non-Persistent Entry Guards ==
Some users might consider configuring non-persistent entry guards so they constantly change. In almost all cases this is inadvisable, because persistent entry guards are a [[#Introduction|critical anonymity feature]]. A far more secure alternative is [[#Alternating Bridges|Alternating Bridges]], although this requires a considerable time investment.
{{project_name_gateway_vm}}).
'''1.''' {{Disable_Tor}}
'''2.''' Modify Tor settings.
{{Open /usr/local/etc/torrc.d/50_user.conf}}
Add.
{{CodeSelect|code=
DataDirectory /var/run/tor
}}
Save.
'''3.''' Enable Tor at the new location.
{{Enable_Tor}}
'''4.''' 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.
}}