Long Wiki Edits Thread

Tor Browser Essentials is very good to have. Nits:

  • Bypass Tor Censorship is too ambiguous. I made the same mistake recently in a forum discussion. Not sure it can be clarified though. There is censorship at ISP level and at destination level. That could use some clarification throughout the wiki. Users usually don’t know if they can’t reach a website if it’s their ISP or destination censoring. Even if they are using Tor.
  • needs a reference from Combining Tunnels with Tor
  • needs a reference from Surfing Posting Blogging - Whonix
1 Like

torjunkie:

See below.

@Patrick

GitHub - tasket/Qubes-VM-hardening: Fend off malware at Qubes VM startup

vm-boot-protect-root - Protects /home/user as above, automatic /rw executable deactivation, whitelisting, checksumming, deployment. Works with appVMs, netVMs, etc. that are template-based.

CAUTION: The -root option by default removes prior copies of /rw/config, /rw/usrlocal and /rw/bind-dirs. This can delete data!

Is the -root option safe for Whonix? This is why I didn’t recommend it in hardening list - not sure.

When setting the -root option up:

Says prior copies. Does not always remove. Only at setup time. This is
how I understand the description. Under that assumption:

  • Whonix (and any non-Whonix VM) generally: loose your data - have a
    backup and restore or create a new VM and migrate there?
  • for new Whonix-Gateway VMs: shouldn’t matter - should be ok - TODO:
    can you check if Tor data (entry guards) in /var/lib/tor will persist
    reboots? (Just add an extra empty text file there.) I guess so. But
    should be tested.
  • for existing Whonix-Gateway VMs: these would loose their Tor entry
    guards - recommend restore

Not trivial. Needs some time. But should be ok to have on advanced
security guide.

1 Like

OK - will do a test.

We should link this Qubes command line cheat sheet somewhere, since it is very handy.

qubes-cheatsheet/qubes-cheatsheet.md at master · Jeeppler/qubes-cheatsheet · GitHub

1 Like

https://phabricator.whonix.org/tag/user_documentation/

I attempted to create an “entry guard technical” and “entry guard non-technical” but it didn’t look good (duplicating information). I settled on adding some info on “traffic analysis” in the introduction hoping users would better understand Tor/entry guards are only a imperfect/partial solution. I’m not even sure if the introduction should be edited at all since its almost verbatim from the Tor wiki?

There are minor edits in other areas but not worth posting here since the entire entry guard chapter would need to be posted along with them. Plus they’re not very important edits.

If any changes are needed please let me know!

The only edit here are to the first paragraph of the wiki/Tor#Entry_Guards

Persistent Tor Entry Guards Introducion

Current practical, low-latency, anonymity designs like Tor fail when the adversary can see both ends of the communication channel. (edits start) If an adversary does not control Tor relays, but is able to monitored both ends of the network, a technique called traffic analysis could be used to glean enough information to profile a user. The term traffic analysis is used to described a multitude of different methodologies which can be used to analyze network traffic patterns. Be that as it may, all of those methods fall into one of two categories.

passive traffic analysis - an adversary will extract features from a data stream on one end of the network and then look for those same features on the other side of the network.

active traffic analysis - the adversary alters the timings of packets on one end the the network according to a specific pattern and looks for that pattern on the other side of the network.

Both of the above methods can be used on cleartext as well as ciphertext (encrypted) traffic, and with a greater number of packets observed, the the greater likelihood that information can be extracted from the network traffic which in turn could then be used to profile a user. To put these dangers into better perspective; (edits end) suppose an adversary controls or watches the Tor relay that a user chooses to enter the network, and also controls or watches the website visited. In this example, 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. Mathematically speaking, choosing many random entry and exit points to the network prevents the user from escaping profiling by this kind of attacker with end-to-end capabilities.

0brand:

Do you think given the questions by the users, pointing the user to the
Tor page (and assuming the user is reading it), do you think it would
answer the user’s questions?

If not, should content be reorganized? Improving headlines? Any headline
that would suite well as a deeplink the user could be given for the
question(s) being asked?

I’m not even sure if the introduction should be edited at all since its almost verbatim from the Tor wiki?

Probably not much.

Mathematically speaking, choosing many random entry and exit points to the network prevents the user from escaping profiling by this kind of attacker with end-to-end capabilities.

That one seems weird. Could lead to users taking wrong choices. In
theory it may be true if the amount of traffic transmitted is so low,
that math doesn’t work. But far from any practical implementation let
alone something the user could do by using “always non-persistent Tor
entry guards” or so.

Let’s replace that sentence by [...].

1 Like

FYI - last released version and a possibly next testers-only VirtualBox version - for changelog tracking:

https://github.com/Whonix/Whonix/compare/14.0.0.6.9-developers-only...whonix:14.0.0.7.3-developers-only

1 Like

Regarding Tor technical information:

IMO, it’s best if our wiki presents only a general, simplified overview and links to the details as provided by TPO. That prevents loss in translation and also reduces maintenance burden. For example, entry guard policy will soon be updated again: torspec/291-two-guard-nodes.txt at main · torproject/torspec · GitHub

3 Likes

I was so focused (obsessed) with trying to find a solution for the probability equations in a way readers could understand that I lost sight of what I was supposed to be doing. 4 days wasted trying to make sense of all those research papers. I don’t think I even learned anything in the process. I knew shortly after posting the proposed wiki changes that I needed to try again.

When I read over the entry guards chapter again I can see what needs to be done now.

Sound good to me.

I appreciate your help on this!

2 Likes

These outstanding documentation items don’t look like much fun at all, but many are necessary.

Personally I want to do more clean up editing work as a current priority, as there is sloppy English, broken links / redirects, outdated info, irrational chapter structures, huge blocks of text, or multiple other irritations on numerous pages on the main ToC. Maybe this appiles to 50% of pages or more (but I am a harsh critic).

If Whonix doesn’t look shiny in the documentation, then it detracts significantly from the product in the user’s mind. No getting around that.

0brand is good with technical stuff, so I’d love to see our new mod tackle some new stuff / instructions / templates if he/she is keen? :slight_smile: 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.

2 Likes

Actually I find much of the phabricator outstanding docs interesting. Keep in mind that I’m the least experienced out of everyone. When I edit/write chapters I do quite a bit of reading and research to make sure I have a solid understanding of the content. This is the part I enjoy the most and what I learn also carries over when a user asks a question. Instead of parroting what is in the wiki. I can answer their question thoroughly.

This difference is –

knowing what to say (I just repeat what is in the wiki chapter)
vs
saying what i know (i have a better understanding on a subject than what is written in the wiki and I use that knowledge to answer the question. Plus add link to wiki chapter)

What it comes down to is editing the current chapters helps with my education. Plus, I enjoy it. So its a win-win all around. :slight_smile:

On the other hand I’d be just as happy with new content edits. I’m sure the wiki could use an update of sorts. We wouldn’t have to try very hard to think of some ideas. hmmm I know! How about a chapter on one_time_pads :yum:

What to do? Editing current chapters or new chapters is fine with me. (and fun for me!). Let me know what you need help with and I’ll get started on it as soon as I finish with my prior commitments. I don’t like to leave things unfinished.

BTW entry_guards chapter is (for the most part) a perfect example of…

broken links / redirects, outdated info, irrational chapter structures, huge blocks of text, or multiple other irritations


One more thing. I took a look at https://qubes-os.org/doc/whonix/ and i was thinking it could be improved. Since everyone is under time restraints. I wanted to officially volunteer as the unofficial Qubes/doc/whonix maintainer (aka doc pull requester).

If there is anything that needs to be added to the page (now and future) let me know. Perhaps links to some of the generalized chapters on security? Non-Whonix users may be interested in these as well.

https://whonix.org/wiki/Computer_Security_Education

https://whonix.org/wiki/Security_Guide

https://whonix.org/wiki/Advanced_Security_Guide

https://whonix.org/wiki/System_Hardening_Checklist

A possibility there is also Whonix wiki instructions that could be added to Qubes/doc/?

2 Likes

0brand:

Actually I find much of the phabricator outstanding docs interesting.

:slight_smile:

Keep in mind that I’m the least experienced out of everyone. When I edit/write chapters I do quite a bit of reading and research to make sure I have a solid understanding of the content. This is the part I enjoy the most and what I learn also carries over when a user asks a question. Instead of parroting what is in the wiki. I can answer their question thoroughly.

Very good!

What to do? Editing current chapters or new chapters is fine with me. (and fun for me!). Let me know what you need help with and I’ll get started on it as soon as I finish with my prior commitments.

As for priority wishes, I’d wish I’d had this one:

Wiki search fallback suggestion - #6 by Patrick

Otherwise it’s hard to define priorities.

One more thing. I took a look at https://qubes-os.org/doc/whonix/ and i was thinking it could be improved.> Since everyone is under time restraints. I wanted to officially
volunteer as the unofficial Qubes/doc/whonix maintainer (aka doc pull
requester).

Yay!

A possibility there is also Whonix wiki instructions that could be added to Qubes/doc/?

I am personally discouraged to contribute to Qubes docs since doing so
is too cumbersome for me.

Hi 0brand,

That would be great if you would take on that Qubes role. And also if you like any of those phabricator items, then go for it! :slight_smile:

Anyhow, re priorities, it would be helpful if you wanted to have a crack at those 2 templates HulaHoop and Patrick wanted + whatever else you think is a priority.

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:

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

2 Likes

Good work 0brand. I’ll have a look and post any suggestions.

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/2090

Manual 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-whonix ProxyVMs 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 Guards

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

  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

Before returning home, the Tor state folder is restored 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, 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).

  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 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:

1 Like

@0brand

See “Using static Disposable VMs for sys-*”

Redirecting…

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 (?) →

http://download.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/linux/13.0.0.1.4/Whonix-Gateway-13.0.0.1.4.ova

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)?