Changes have been made to my previous post Tor#Entry_Guards
Edits added:
Non-Persistent Entry Guards
1 Like
Sorry about the delay - too busy these days.
PS If Qubes didn’t put up the Disp-VM stuff yet, maybe we just go ahead and create the page in the wiki.
Suggestion (mostly rewording):
Introduction
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. [ref]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.[/ref]
[INFO BOX]
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.[CLOSE INFO BOX]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. [ref]Prop 291 indicates a 3.5 month guard rotation.[/ref] [ref]The Tor Project is currently considering shifting to two guards per client for better anonymity, instead of having one primary guard in use.[/ref] [ref]https://github.com/torproject/torspec/blob/master/proposals/291-two-guard-nodes.txt[/ref]
Warning: In some situations it is safer to not use the usual guard relay!
Guard Fingerprinting
While natural guard rotation is recommended, there are some corner cases in which an adversary could fingerprint the entry guards 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:
Clone Whonix-Gateway (sys-whonix) with New Entry Guards.
Regenerate the Tor State File after Saving the 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.
Forum discussion:
[…]persistent-tor-entry-guard-relays-can-make-you-trackable-across-different-physical-locations/2090Manual Rotation of Tor Guards
Security and Performance Related Issues
Users may be tempted to create a new Whonix-Gateway (
sys-whonix) in the following circumstances:
- Tor bootstrapping is slow or inconsistent.
- Tor logs show warnings about possible route manipulation or other attacks.
- System logs indicate possible attacks on Whonix, Tor or other processes. [ref]For example in AppArmor logs.[/ref]
- Tor throughput is slow or inconsistent due to collapsing circuits or other factors.
- A large volume of Tor data might be revealed if the Whonix-Gateway is exploited. [ref]For example after a long period of sustained use.[/ref]
- A recent Tor guard rotation has resulted in poor throughput due to capacity issues.
Creation of a new Whonix-Gateway (
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 [ref]Four guard rotations in 14 months.[/ref] 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 Tor guard rotation 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:
[blockquote]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.[/blockquote]
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. [ref]This thinking aligns with intelligence disclosures which deem all Tor users to be persons of interest to state-level adversaries.[/ref]
Warning: Users considering using disposable
sys-whonixProxyVMs in Qubes R4 are warned that this technique severely degrades anonymity, since 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. [ref]Users should note that regenerating the Tor state file poses the same anonymity risks as outlined in this section.[/ref]
Mitigate the Threat of Guard Fingerprinting
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 GuardsIt 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-tempVM).
– Virtualbox: Follow [these instructions] to create a VM snapshot.
– Qubes-Whonix: Right-click onsys-whonix→Clone VM- Regenerate the Tor State File.
Regenerate the Tor State After Saving the Tor State Folder
[INFO BOX]Non-Qubes-Whonix only![CLOSE INFO BOX]
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.
In Whonix-Gateway konsole, stop Tor.
sudo systemctl stop tor@default
In Whonix-Gateway konsole, remove the temporary Tor state folder.
sudo rm -r /var/lib/tor
Restore the Tor state folder.
sudo mv ~/tor /var/lib
Restart Tor.
sudo systemctl restart tor@default
Before returning home, the Tor state folder is restored to its original settings.
In Whonix-Gateway konsole, Stop Tor.
sudo systemctl stop tor@default
In Whonix-Gateway konsole, move the Tor state folder to the $HOME directory.
sudo mv /var/lib/tor ~/
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, consider 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).
Disable_Tor.
Configure Tor to use bridges. Refer to the Bridges documentation.
Enable Tor using whonixsetup / whonix-setup-wizard at the new location.
Before leaving this location, disable Tor and add a different bridge address if traveling to a new 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.
These rest looks fine to me.
1 Like
That looks great! From now on when posting edits, I’ll format the way you did here. 
1 Like
See “Using static Disposable VMs for sys-*”
You decide:
a) Only refer to this link in the wiki; or
b) Use your stuff.
1. Can .onion links be added to all those download pages for VirtualBox etc where people are downloading with Tor Browser?
Right now we have the clearnet address links only e.g.
https://download.whonix.org/linux/13.0.0.1.4/Whonix-Gateway-13.0.0.1.4.ova
Which would change to (?) →
2. I also note re: VLC →
[SECURITY] [DSA 4203-1] vlc security update
Hans Jerry Illikainen discovered a type conversion vulnerability in the MP4 demuxer of the VLC media player, which could result in the execution of arbitrary code if a malformed media file is played.
This update upgrades VLC in stretch to the new 3.x release series (as security fixes couldn’t be sensibly backported to the 2.x series). In addition two packages needed to be rebuild to ensure compatibility with VLC 3; phonon-backend-vlc (0.9.0-2+deb9u1) and goldencheetah (4.0.0~DEV1607-2+deb9u1).
VLC in jessie cannot be migrated to version 3 due to incompatible library changes with reverse dependencies and is thus now declared end-of-life for jessie. We recommend to upgrade to stretch or pick a different media player if that’s not an option.
Warning required for VLC users in Whonix 13 (Jessie)?
torjunkie:
1. Can .onion links be added to all those download pages for VirtualBox etc where people are downloading with Tor Browser?
Right now we have the clearnet address links only e.g.
https://download.whonix.org/linux/13.0.0.1.4/Whonix-Gateway-13.0.0.1.4.ova
Which would change to (?) →
Forcing Onion Connections on whonix.org applies?
Or you mean the hidden by default download table? I don’t mind much
about that one since hidden by default. That can be super complex super
secure.
2. I also note re: VLC →
[SECURITY] [DSA 4203-1] vlc security update
Hans Jerry Illikainen discovered a type conversion vulnerability in the MP4 demuxer of the VLC media player, which could result in the execution of arbitrary code if a malformed media file is played.
This update upgrades VLC in stretch to the new 3.x release series (as security fixes couldn’t be sensibly backported to the 2.x series). In addition two packages needed to be rebuild to ensure compatibility with VLC 3; phonon-backend-vlc (0.9.0-2+deb9u1) and goldencheetah (4.0.0~DEV1607-2+deb9u1).
VLC in jessie cannot be migrated to version 3 due to incompatible library changes with reverse dependencies and is thus now declared end-of-life for jessie. We recommend to upgrade to stretch or pick a different media player if that’s not an option.
Warning required for VLC users in Whonix 13 (Jessie)?
Yes.
For now the wiki should point to this Qubes doc chapter. The claims that are made in our version should be verified ( i.e can use custom firewall rule-sets). Its always possible that I missed something and although custom rules cannot be used with Whonix, they can be used with other VMs.This could make the system vulnerable and is not a chance that should be taken when there is an option that has already passed review. No custom rule-sets but a second non-DispVM firewall-VM can be used. Lets give marmarek whatever time he needs to ensure these instructions are sound.
The edits will be ready for your review later today 
Nitpick @torjunkie:
Symmetric Keys A older method of encryption. One key is used for both
encryption and decryption.
Older implies obsolete? Luks encryption is symmetric. And it works well.
Not outdated / obsolete at all. Symmetric encryption even won’t fall
short against Post-Quantum Cryptography (PQCrypto). So when practical
(not very much when communicating with people you can’t meet in person),
I would even prefer symmetric encryption.
The latter sentence worth pointing out in the wiki? @HulaHoop
2 Likes
1 Like
Changing to this makes sense →
Symmetric encryption depends on using a password to encrypt the single key used for both encryption and decryption.
2 Likes
When you have a free moment could you please unlock the following template for editing. I’ll be sure to complete the edits promptly this time around. 
https://www.whonix.org/wiki/Template:Persistent_Tor_Entry_Guards_Introduction
I also have a questions. In the introduction, for the text that I added bold type, should they be links to the stated instructions?
P.S. Thanks for all the help with this chapter!
1 Like
0brand:
When you have a free moment could you please unlock the following template for editing. I’ll be sure to complete the edits promptly this time around.
I’ve promoted your account to wiki admin just now so you can do that.
(Doesn’t require remove edit lock then. Can edit right away as admin.)
2 Likes
Tor entry guards edits complete.
https://www.whonix.org/wiki/Template:Persistent_Tor_Entry_Guards_Introduction
https://whonix.org/w/index.php?title=Tor&oldid=33697&diff=cur
2 Likes
Will fix that.
That’s great 0brand, thanks for doing the editing.
Yes, agree links are better.
1 Like
I made few mistakes when editing Tor entry guards.
- failed to format subheading
- failed to format a “Info Box” and “Warning”
- duplicate text
- did not use the same formatting style throughout page
All have been fixed with the latest proposed edits.
https://whonix.org/w/index.php?title=Tor&oldid=33864&diff=cur
Sorry about that. Won’t happen again.
//cc @torjunkie
1 Like
Trust page → Fixed (and defluffed)
Outstanding Qs re: this page
- Verifiable builds. Not currently possible for Whonix I understand. If so, this part needs to change “Some readers might be curious why Whonix is verifiable…” (Whonix is also marked in Red in the table as a “no” for verifiable).
- The onion link to Tor signing keys is wrong (doesn’t resolve). Does anyone know where signing keys are on the Tor Project .onion these days i.e. tor.xxxxxxxxx.onion/signingkeys?
No problem 0brand - multiple fix-ups are the norm.
One thing you did cut from the edits was the number of bits of info related to exposure of 1, 2 or 3 guards. I think that is still useful to footnote somewhere. Maybe even the fingerprinting or data collection page.
I’ll replace the footnote in entry guards chapter.
Additional fingerprinting content was added to “Tor entry guards”. Maybe add some of that content under a new “Entry Guards” subheading in “fingerprinting” and “Data Collection” chapters.
I’ll get it done!
1 Like
torjunkie:
Trust page → Fixed (and defluffed)
- Verifiable builds. Not currently possible for Whonix I understand.
Correct.
1 Like
An old attack was observed in the wild that exploited a JavaScript vulnerability in Firefox. [11] The observed version of the attack collected the hostname and MAC address of the victims’ computers, and sent that information to a remote web server. This threat is partially mitigated nowadays by the development of a security slider in the Tor Browser Bundle, which prevents the execution of JavaScript code completely with the correct settings.
The real Q is would it have leaked the MAC address and hostname if successfully run in Whonix-Workstation? I gather not for MAC address, yes for generic Whonix-WS hostname, but that needs to be explicitly clarified I think.
Another nit, spacing on the templates that were edited. After bullet points or mboxes, an extra carriage return is usually required so it doesn’t look bunched up.
@Patrick this Whonix History page on the main ToC is severely outdated i.e. doesn’t show versions beyond 0.4.5.
http://kkkkkkkkkk63ava6.onion/wiki/History
Since we are nearly at Whonix 14, I think this should be removed from the main ToC, and simply sit in a link somewhere stating “Users can read more about the early history of Whonix here.”
Either that, or insert descriptions for > 0.4.5 → Whonix 13. Which seems a lot of work for very little benefit.
Another option, we just keep the top “history” section, and put all the version info in a separate “Whonix Version” wiki page, since it is ancient and almost nobody will care / read it anyhow.
2 Likes
In the “Comparison with Others” chapter, it refers to “Qubes OS TorVM” as part of all the comparison.
It is deprecated, see:
On that basis, recommend we:
- Note that; or
- Delete all the stuff related to TorVM in the wiki page; or
- Send all that info to a deprecated page for posterity, since it’s not a fair comparison if the project is dead. Then I would footnote: “QubesOS TorVM was previously part of this comparison, but it has been deprecated. Interested readers can refer to the historical comparison here [embedded link].”
1 Like