Last update: March 17, 2019. This website uses cookies. By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent. More information

 Actions

Tor Entry Guards

About this Tor Entry Guards Page
Support Status stable
Difficulty easy
Maintainer 0brand
Support Support

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. [1] However, this feature won't become really useful until Tor moves to a "directory guard" design as well.

Source and License, see footnote: [2]

Guard Fingerprinting[edit]

Many well-known, enhanced anonymity designs like 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. [3]

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. [4] [5] [6]

Fingerprinting Method[edit]


While natural guard rotation is recommended, in some situations it is safer to not use the usual guard relay! There are some corner cases in which an adversary could fingerprint the entry guard(s) [7] 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.

For details on how this is possible, press Expand on the right.

Consider the following scenario. A user connects to Tor via a laptop at their home address. An advanced adversary has observed the client-to-guard-node network path to discover the user's entry point to the Tor network.

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.

To understand the potential threat, consider the following:

  • There are only around 3,000 Tor guards in 2019. [8]
  • By design, Tor is picking one primary guard and using it for a few months. Since the Tor user base is relatively small, it is possible that a guard might only be used by one person in an entire region.
  • As the IP address of Tor entry guards is static and Tor network traffic is easily distinguishable, this information becomes public knowledge.
  • It is feasible that if a user-guard relationship is unique in a city location, and that user moves, it is likely (but not certain) that there was a location change.
  • At the event, the user might be the only one using Tor (or among a handful).
  • If the user posts about the event and an adversary who is passively monitoring network traffic conducts the same successful observation of the client-to-guard network path, then it’s likely the "anonymous" posts will be linked with the same person who normally connects to that guard at home.

The relative uncommonness of Tor usage simply 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: [9]

  1. Clone Whonix-Gateway ™ (sys-whonix) with New Entry Guards.
  2. Regenerate the Tor State File after Saving the Current Tor State.
  3. Configure Tor to use Alternating 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

Increase Protection from Malicious Entry Guards: One Guard per Application[edit]

Whonix ™ developer HulaHoop recently approached Tor researcher, Tariq Elahi, to discuss how exposure to malicious guards in multi-Workstation scenarios could be measured. It was discovered that 1 guard/client per internet-connected program (not identity!) is the safest possible configuration. In fact, the probability of a network adversary observing a user's activities is lower than the default scenario, whereby one Tor Entry Guard is relied upon for all applications.

To apply this configuration, follow these steps:

  1. Import a Whonix-Gateway ™ into the hypervisor that has never been started.
  2. Take a snapshot and name it "Original".
  3. Start Whonix-Gateway ™ and wait for Tor to finish bootstrapping (connecting).
  4. After Tor has connected, shutdown Whonix-Gateway ™ and take another snapshot - the naming convention should match the intended activity, such as "Email".
  5. This snapshot should be used with all Whonix-Workstation ™ snapshots related to/called "Email", whether it is identity "John Doe", "Jane Doe" and so on. Note the Workstations should also be generated separately from a clean baseline.

When a separate activity is required such as IRC, users should revert to the Whonix-Gateway ™ snapshot (labelled "Original"), then repeat the same steps. That is, allow it to boot and connect to Tor, shut it down, then take a snapshot entitled "IRC".

If you need to run multiple applications at the same time, then consider cloning the VMs. [10]

Extra Precautions[edit]

There is a small chance that Entry Guards could be reused for a separate application group, which would increase observation by an adversary. In the absence of a technological solution to automatically prevent such scenarios, it is encouraged to manually check the Tor node list on the Gateway using Onion Circuits for duplicated Entry Guards that are shared by other snapshots. Erase and re-take a different snapshot if that is the case. [11]

Important Caveats[edit]

  • Do not start the application on the Workstation before taking the Gateway snapshot. This is to prevent it from generating data on the Gateway -- such as Onion Service descriptors -- that can be linked across sessions or detected in the event of the Workstation being infected. [12]
  • If you use multiple instances of the same application concurrently -- email accounts John Doe and Jane Doe in the example above -- make sure each gets its own Gateway VM (cloned from the "Email" snapshot for example) and its own isolated network. They should never share the same Gateway because a malicious Workstation can:
    • Sniff data on the shared isolated network; and
    • Also manipulate the common Tor client into divulging information belonging to the other application.

Manual Rotation of Tor Guards[edit]

Creating a new Whonix-Gateway ™ (sys-whonix) will likely lead to a new set of Tor entry guards, which is proven to degrade anonymity.

Anonymity 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 suggestive of route manipulation attacks or other oddities.
  • System 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 Whonix-Gateway ™ is infected, particularly after a long period of use.

Manual Guard Rotation Threats[edit]

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 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 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: [13]

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[edit]

If users feel compelled in their circumstances to proceed despite the anonymity risks, then it may be safer to first try:

The safest decision is to persist with poor performance and wait for normal guard rotation.

Mitigate the Threat of Guard Fingerprinting[edit]

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 Whonix-Gateway ™ (sys-whonix) with new guards.

Clone Whonix-Gateway ™ (sys-whonix) with New Entry Guards[edit]


It is possible to clone the current Whonix-Gateway ™ (sys-whonix) 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 Whonix-Gateway ™ until returning home.

Create a Whonix-Gateway ™ (sys-whonix) clone and name it Whonix-Gateway ™-temp (sys-whonix-temp):

  1. Virtualbox: follow these instructions to create a VM snapshot.
    Qubes-Whonix ™: In Qube Manager, Right-click on sys-whonixClone qube
  2. Regenerate the Tor State File.

Regenerate the Tor State After Saving the Tor State Folder[edit]


Before arriving at the remote location, the Whonix-Gateway ™ Tor state folder is moved to the $HOME directory and the Tor state file is regenerated. Perform all the following steps in Whonix-Gateway ™ konsole.

1. Stop Tor.

sudo systemctl stop tor@default

2. Move the Tor state folder to the $HOME directory.

sudo mv /var/lib/tor ~/

3. Restart Tor.

sudo systemctl restart tor@default

Before returning home, the Tor state folder is restored to its original settings.

1. Stop Tor.

sudo systemctl stop tor@default

2. 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

Alternating Bridges[edit]

If 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.

Complete the following steps in Whonix-Gateway ™ (sys-whonix).

1. Disable Tor using Anon Connection Wizard (safest option).

Start Anon Connection Wizard.

If you are using Qubes-Whonix ™, complete the following steps.

Qubes App Launcher (blue/grey "Q")Whonix-Gateway ™ ProxyVM (commonly named sys-whonix)Anon Connection Wizard

If you are using a graphical Whonix-Gateway ™, complete the following steps.

Start MenuApplicationsSystemAnon Connection Wizard

If you are using a terminal Whonix-Gateway ™, type.

kdesudo anon-connection-wizard

Choose the Disable Tor option. Press next.

2. Configure Tor to use bridges. Refer to the Bridges documentation.

3. Enable Tor at the new location.

Enable Tor using Anon Connection Wizard (easiest option).

Start Anon Connection Wizard.

If you are using Qubes-Whonix ™, complete the following steps.

Qubes App Launcher (blue/grey "Q")Whonix-Gateway ™ ProxyVM (commonly named sys-whonix)Anon Connection Wizard

If you are using a graphical Whonix-Gateway ™, complete the following steps.

Start MenuApplicationsSystemAnon Connection Wizard

If you are using a terminal Whonix-Gateway ™, type.

kdesudo anon-connection-wizard

Choose the Enable Tor option. Press next.

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 sys-whonix Instance[edit]


In some circumstances Qubes-Whonix ™ users might want to copy the Tor state and 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 [15] 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 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.

sudo systemctl stop tor@default

2. In sys-whonix-new, remove the Tor state file.


sudo su

sudo rm /var/lib/tor/*

3. In sys-whonix-old, stop Tor.

sudo systemctl stop tor@default

4. In sys-whonix-old, copy the Tor state file across to sys-whonix-new.

sudo qvm-copy /var/lib/tor 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.

ls ~/QubesIncoming/sys-whonix-old/tor

The output should include the files below.

  cached-certs cached-microdescs lock
  cached-microdesc-consensus cached-microdescs.new state

6. In sys-whonix-new, move the newly copied Tor state file to /var/lib/tor

sudo mv ~/QubesIncoming/sys-whonix-old/tor/* /var/lib/tor

7. In sys-whonix-new, change ownership of all files in the Tor state folder to debian-tor

sudo chown -R debian-tor:debian-tor /var/lib/tor

8. In sys-whonix-new, start Tor.

sudo systemctl start tor@default

9. In sys-whonix-new, run whonixcheck to verify Tor is functioning properly. [16]

whonixcheck

Copy Tor Configuration Options (torrc) to Another sys-whonix[edit]

These instructions copy 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. [17]

qvm-copy /usr/local/etc/torrc.d/50_user.conf 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, list the QubesIncoming directory to ensure the torrc options were copied over successfully.

cat ~/QubesIncoming/sys-whonix-old/50_user.conf

3. In sys-whonix-new, move the 50_user.conf options from the QubesIncoming directory to the 50_user.conf file.

sudo mv ~/QubesIncoming/sys-whonix-old/50_user.conf /usr/local/etc/torrc.d/50_user.conf

4. In sys-whonix-new, change ownership of the Tor configuration file.

sudo chown -R root:root /etc/tor

5. In sys-whonix-new, restart Tor so the newly copied Tor config options take effect.

sudo systemctl restart tor@default

6. In sys-whonix-new, run whonixcheck to verify Tor is functioning properly. [18]

whonixcheck

Unsafe Guard Rotation Methods[edit]

Fresh Tor Entry Guards by Regenerating the Tor State File[edit]


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.

Complete the following steps in Whonix-Gateway ™ (Qubes-Whonix ™: sys-whonix).

1. Disable Tor using Anon Connection Wizard (safest option).

Start Anon Connection Wizard.

If you are using Qubes-Whonix ™, complete the following steps.

Qubes App Launcher (blue/grey "Q")Whonix-Gateway ™ ProxyVM (commonly named sys-whonix)Anon Connection Wizard

If you are using a graphical Whonix-Gateway ™, complete the following steps.

Start MenuApplicationsSystemAnon Connection Wizard

If you are using a terminal Whonix-Gateway ™, type.

kdesudo anon-connection-wizard

Choose the Disable Tor option. Press next.

2. Delete Tor's state file.

sudo rm /var/lib/tor/state

3. Enable Tor at the new location.

Enable Tor using Anon Connection Wizard (easiest option).

Start Anon Connection Wizard.

If you are using Qubes-Whonix ™, complete the following steps.

Qubes App Launcher (blue/grey "Q")Whonix-Gateway ™ ProxyVM (commonly named sys-whonix)Anon Connection Wizard

If you are using a graphical Whonix-Gateway ™, complete the following steps.

Start MenuApplicationsSystemAnon Connection Wizard

If you are using a terminal Whonix-Gateway ™, type.

kdesudo anon-connection-wizard

Choose the Enable Tor option. Press next.

Configure Non-Persistent Entry Guards[edit]

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 critical anonymity feature. 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 ™ (sys-whonix).

1. Disable Tor using Anon Connection Wizard (safest option).

Start Anon Connection Wizard.

If you are using Qubes-Whonix ™, complete the following steps.

Qubes App Launcher (blue/grey "Q")Whonix-Gateway ™ ProxyVM (commonly named sys-whonix)Anon Connection Wizard

If you are using a graphical Whonix-Gateway ™, complete the following steps.

Start MenuApplicationsSystemAnon Connection Wizard

If you are using a terminal Whonix-Gateway ™, type.

kdesudo anon-connection-wizard

Choose the Disable Tor option. Press next.

2. Modify Tor settings.


Open /usr/local/etc/torrc.d/50_user.conf.

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 MenuApplicationsSettings/usr/local/etc/torrc.d/50_user.conf

If you are using a terminal-only Whonix-Gateway ™, complete the following steps.

sudo nano /usr/local/etc/torrc.d/50_user.conf

Add.

DataDirectory /var/run/tor

Save.

3. Enable Tor at the new location.

Enable Tor using Anon Connection Wizard (easiest option).

Start Anon Connection Wizard.

If you are using Qubes-Whonix ™, complete the following steps.

Qubes App Launcher (blue/grey "Q")Whonix-Gateway ™ ProxyVM (commonly named sys-whonix)Anon Connection Wizard

If you are using a graphical Whonix-Gateway ™, complete the following steps.

Start MenuApplicationsSystemAnon Connection Wizard

If you are using a terminal Whonix-Gateway ™, type.

kdesudo anon-connection-wizard

Choose the Enable Tor option. Press next.

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.

Notes[edit]

The proposed Tails solutions towards AdvGoalTracking have disadvantages [19] [20] 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 alternative 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 can be found here.

Footnotes[edit]

  1. Even though the attacker can't discover the user's destinations in the network, they still might target a list of known Tor users.
  2. 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.
  3. 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.
  4. Prop 291 indicates a 3.5 month guard rotation.
  5. The Tor Project is currently considering shifting to two guards per client for better anonymity, instead of having one primary guard in use.
  6. https://github.com/torproject/torspec/blob/master/proposals/291-two-guard-nodes.txt
  7. The entropy associated with one, two or three guards is 9, 17 and 25 bits, respectively.
  8. https://metrics.torproject.org/relayflags.html
  9. As concluded in ticket research non-persistent Tor directory guards, these are covered by the following instructions.
  10. HulaHoop
    Subject: Re: Fwd: Re: Tor revised guard behavior & chances of malicious guard
    To: Tariq Elahi, adrelanos@riseup.net
    
    
    Tariq Elahi:
    >
    > The short story is that things get worse very quickly, but there is hope.
    > The analysis below assumes only the adversary that runs guards and not
    > the local adversary like the host OS or the {{project_name}} processes themselves.
    > In my analysis I assume a hypothetical adversarial guard bandwidth of
    > 10% of the entire network. This is an arbitrary number since we don't
    > know the real number, but it serves to show the trends as we increase
    > the guards per client and number of clients per user. I do the kind of
    > analysis we do in the Conflux[1] paper which is very relevant here,
    > especially Table 3 and its discussion in section 5.2. I update the
    > numbers and extend that analysis for the scenarios you have described.
    >
    > 1. 1 guard/client, 1 client/user.
    > The adversary (i,e, the compromised guard) will have the ability to
    > observe 10% of the clients and hence 10% users. This is the situation
    > today.
    >
    > 2. 2 guards/client, 1 client/user.
    > This is worse than 1 above. There is now a 18% probability that only one
    > of the guards is compromised per client and a 1% chance that two guards
    > are compromised per client. The probability of at least one bad guard is
    > hence 19%. There really is not a real distinction between one or two bad
    > guards from the user perspective since in both situations the client
    > will go through a malicious guard in a short period of time, since the
    > guard is picked uniformly at random from the guard set.
    >
    > 3. 1 guard/client, 2 clients/user.
    > The observable clients again increase to 19% from the base 10% in 1
    > above. This means that if the user split her app (or group of apps)
    > across the clients then there is a 19% chance that at least one of the
    > app (groups) is compromised. However, for each client there is still
    > only a 10% chance that a malicious guard is present. Is this
    > configuration better than scenario 2 above? Perhaps, but let's look at
    > the following scenario first.
    >
    > 4. 2 guards/client, 2 clients/user.
    > The observable clients increases to 54%. This means that there is a 54%
    > chance that at least one bad guard is present. This is worse than all
    > the other scenarios above. However, if we fix apps (or groups of apps)
    > to particular clients then we can compare to scenario 2 where the app
    > group/client is analogous and the same analysis holds. Then, for each
    > client there is again a 19% chance that there is a malicious guard
    > present. If we compare to 3 above we can see that if we only use 1
    > guard/client then we can drop the exposure back down to 10% for that
    > client and hence app group.
    >
    > Taking the above into account we can get good results by keeping the
    > guard set size to 1 and users spin up one client for each app. Then we
    > can achieve at most 10% of apps compromised at *any given time* but not
    > simultaneously. We can call this scenario (which is an extension of
    > scenario 3) the 1 guard/app scenario (1G/A). See the appendix for more
    > tweaks to decrease guard exposure.
    >
    > If we want to consider 1G/A, then the next question for your user base
    > is that is it better to either 1) have some portion of your apps
    > compromised at *all* times (scenario 1G/A) or 2) have *all* your apps
    > compromised some portion of the time (scenario 1). Tor tends to bend
    > towards option 2, but then they have not considered the option of
    > multi-client usage since it doesn't improve the situation in a
    > non-compartmentalized setting, unlike the {{project_name}} situation. I believe
    > that option 2 is flawed because you never know if you are in fact
    > currently compromised or not. It might be better to go ahead with
    > assuming that you are compromised and mitigating that compromise to some
    > portion of your network activity than all or nothing, which is what
    > option 1 provides.
    >
    > I hope that answers your questions. Please do not hesitate to get in
    > touch again if you would like to discuss further. I think this is a very
    > interesting problem area and would be happy to contribute to improving
    > the situation.
    >
    > Best regards,
    > Tariq Elahi
    >
    >  [1] http://cacr.uwaterloo.ca/techreports/2013/cacr2013-16.pdf
    >
    > Appendix
    > We can do better if we allow a user's clients to look at each other's
    > lists to exclude guards that are already picked. The benefit would be
    > that once the bad bandwith has been assigned it can no longer affect
    > subsequent guard selections. However, clients looking at each other's
    > memory space will compromise your vision of process containment. A zero
    > knowledge/oblivious method for comparing guard lists might work to avoid
    > this problem, and indeed the adversarial response will be weak since the
    > best they can do is spread their bad bandwidth over many relays and at
    > best return to the original exposure rate (e.g. 10%) but now with added
    > costs of running many more relays.
    >
    
    
    Thanks for getting back to us. With your permission I'd like to quote
    your reply on our wiki.
    
    IIRC Tor is currently using a 2 guard per client config but will be
    moving to 1 because of research showing it's safer. Should we force the
    use of one guard even if it's not the standard configuration of most Tor
    users at the moment?
    
    With 1G/A being the best option it would translate to cloning the Tor VM
    (for as many separate Apps desired) before first run - to ensure they
    don't share the same guard correct?
    
    
    ***
    
    I'm trying to think how the different Tor instances can look at each
    other's guard lists across different VMs. Probably through using
    inter-VM communication or something similar.
    
    Spawning multiple Tor instances on the same Gateway VM would be easier
    but getting each instance to use only it's own internal network that
    connects to its unique App VM is not as straight forward as the separate
    VM approach.
  11. Tariq Elahi
    Subject: Re: Fwd: Re: Tor revised guard behavior & chances of malicious guard
    To: HulaHoop, adrelanos@riseup.net
    
    
    Hi,
    
    I have replied inline below.
    
    
    On 27/09/18 17:22, HulaHoop wrote:
    > [snip]
    >
    > Thanks for getting back to us. With your permission I'd like to quote
    > your reply on our wiki.
    Sure, but I would to take a look at what the context and quote is if that is alright, please.
    >
    > IIRC Tor is currently using a 2 guard per client config but will be
    > moving to 1 because of research showing it's safer. Should we force the
    > use of one guard even if it's not the standard configuration of most Tor
    > users at the moment?
    I thought Tor was using one guard and thinking of moving to two. Is it the other way around?
    Forcing some users to do something different from other users partitions the user base and this is considered not a good thing to do in general.
    >
    > With 1G/A being the best option it would translate to cloning the Tor VM
    > (for as many separate Apps desired) before first run - to ensure they
    > don't share the same guard correct?
    They could share the same guard if it gets picked randomly. The likelihood of this happening at random depends on the bandwidth of the guard so it might not be as rare. The trick is making sure you don't pick an already used guard without needing to divulge information about all other apps' guards.
    >
    >
    > ***
    >
    > I'm trying to think how the different Tor instances can look at each
    > other's guard lists across different VMs. Probably through using
    > inter-VM communication or something similar.
    >
    > Spawning multiple Tor instances on the same Gateway VM would be easier
    > but getting each instance to use only it's own internal network that
    > connects to its unique App VM is not as straight forward as the separate
    > VM approach.
    >
    Indeed, communication between the VMs is needed. Perhaps a mediation agent that could help facilitate the list matching process?
    
    I am quite interested in this now. Perhaps we should talk more about this over chat if that will help.
    
    Tariq
  12. https://lists.torproject.org/pipermail/tor-dev/2016-November/011636.html
  13. https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters
  14. 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-Whonix ™ 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.
  15. As the same Tor entry guard is used.
  16. If Tor fails to start, verify the Tor folder has the proper file permissions with the following command: sudo ls -l /var/lib/tor
  17. Note: From Whonix ™ 14 onward, all unique Tor configurations (torrc) options must be stored in /usr/local/etc/torrc.d/50_user.conf and nowhere else.
  18. 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.
  19. https://tails.boum.org/blueprint/persistent_Tor_state/
  20. https://blog.torproject.org/blog/tor-weekly-news-%E2%80%94-june-17th-2015#A_persistent_Tor_state_for_Tails

License[edit]

Whonix ™ Tor Entry Guards wiki page Copyright (C) Amnesia <amnesia at boum dot org>
Whonix ™ Tor Entry Guards wiki page Copyright (C) 2012 - 2019 ENCRYPTED SUPPORT LP <adrelanos@riseup.net>

This program comes with ABSOLUTELY NO WARRANTY; for details see the wiki source code.
This is free software, and you are welcome to redistribute it under certain conditions; see the wiki source code for details.


No user support in comments. See Support.

Comments will be deleted after some time. Specifically after comments have been addressed in form of wiki enhancements. See Wiki Comments Policy.


Anonymous user #1

2 months ago
Score 0 You
"Enable Tor using whonixsetup / whonix-setup-wizard at the new location." (x3 in this page). Should be Anon Connection Wizard?

Patrick

2 months ago
Score 0++
Yes.
Add your comment
Whonix welcomes all comments. If you do not want to be anonymous, register or log in. It is free.


Random News:

Please help us to improve the Whonix Wikipedia Page. Also see the feedback thread.


https | (forcing) onion

Share: Twitter | Facebook

This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! Read, understand and agree to Conditions for Contributions to Whonix ™, then Edit! Edits are held for moderation.

Copyright (C) 2012 - 2019 ENCRYPTED SUPPORT LP. Whonix ™ is a trademark. Whonix ™ is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Freedom Software license as Whonix ™ itself. (Why?)

Whonix ™ is a derivative of and not affiliated with Debian. Debian is a registered trademark owned by Software in the Public Interest, Inc.

Whonix ™ is produced independently from the Tor® anonymity software and carries no guarantee from The Tor Project about quality, suitability or anything else.

By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent. Whonix ™ is provided by ENCRYPTED SUPPORT LP. See Imprint.