Long Wiki Edits Thread

Website
802

Pending approval:

http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/w/index.php?title=Documentation&oldid=34457&diff=cur

803

Really strange. Since not shown anywhere. Check if done now please.

1 Like
804

Thanks! That’s done. Now I must fix a bunch of links.

→ Fixed Qubes/Install page

That testers wiki page needs a bit of a rework. They could test things that have failed in recent times e.g. Qubes or Whonix bugs maybe? E.g. upgrade to Whonix 14 applies proper anon tags etc

1 Like
805

Feedback regarding Tor - Whonix

Cannot deactivate automatically start default netvm on boot. · Issue #3554 · QubesOS/qubes-issues · GitHub

806

My answer:

http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/w/index.php?title=Fingerprint&oldid=33831&diff=cur

[…]

For example, if a user connects from multiple physical locations with persistent guards/bridges, then an adversary capable of monitoring this network activity can recognize that all connections stem from the same person. This is why it is recommended to use methods which mitigate the risk, such as using new entry guards, configuring alternate bridges and so on.

Nick Mathewson from The Tor Project also suggests additional precautions when moving networks, including: [[tor-dev] entry guards and linkability tor-dev: entry guards and linkability]

  • [[MAC_Address|Spoofing the MAC address]] with randomized values on each move.

  • Absolutely preventing non-Tor connections.

  • Ensuring a unique set of entry guards (bridges) is used for each network the user connects from. Note: this is not a recommendation for non-persistent guards, because a hostile DHCP server might provide new IPs until a hostile guard is chosen.

  • Minimizing the threat of stored Tor state files which record every network visited.

We also note in guard fingerprinting section:

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 changed its design in 2014 to have a solitary primary guard node, and increased the set period for guard rotation.

etc.

So if core Tor Project devs think it is a risk i.e. guard enumeration across possible different networks that the adversary is monitoring, then I think it is a realistic threat.

Particularly since he also advocates MAC spoofing etc in combination.

So, to put the Q back to Andrew, why is Nick Mathewson wrong?

PS Did I mention there are hundreds of broken links? I’m making my way through the entire ToC, but will take some time.

1 Like
807

I don’t think @adw is trying to say Nick is wrong. He trying to understand this better.

With the following…

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.

He’s just wondering if we could elaborate on that to explain that better.

We don’t seem to have a section that says there are Y entry guards in total and we’re picking X (actually just 1) of them and sticking to them. Since the number of Tor users is small, one is likely the only one in that region using that same Tor entry guard. The Tor entry guard stays on the same IP all the time. All entry guards are easily known public knowledge to all adversaries since the list is public. So the list of IPs of Tor entry guards is public. And now there is just 1 user in 1 city that uses that entry guard. If that user moves, it is likely (not certain) that this user moved location.

If there are X Tor users (maybe just 1) at an event, posting about that event in an adversary monitored forum while or shortly after it happened, then it’s likely that it’s the one using the same entry guard in another place.

I don’t think we explain this anywhere in the wiki?

1 Like
808

I understand and acknowledge the fingerprinting risk described here. I have no reason to think (and never suggested that) Nick Mathewson is wrong. I do, however, think that Tor Documentation for Whonix Users fails to make clear that this particular fingerprinting risk is the one it’s describing in the section I quoted in Cannot deactivate automatically start default netvm on boot. · Issue #3554 · QubesOS/qubes-issues · GitHub (more on this below).

Yes, this. But also:

(emphasis mine)

The fingerprinting risk is that the user is using the same entry guard at two different locations. An adversary surveilling the local networks at these locations can determine with a reasonably high degree of confidence that it’s the same user at both locations. However, this does not explain how this deanonymizes the user. The fact that “the user decides to anonymously blog about what transpired using the same laptop” makes it clear that the relevant sense of deanonymization here is having the real-life identity of the user linked to the authorship of the blog post.

As I wrote in https://github.com/QubesOS/qubes-issues/issues/3554#issuecomment-407609005:

Again, the new network can see only that I’m using Tor by using this entry guard. They still can’t see beyond the entry guard, because that’s the point of entry guards, so they still can’t see what I’m doing anonymously via Tor.

In other words, suppose my use of the same entry guard has allowed the adversary to learn:

  • My real identity
  • The Tor entry guard I used at both locations

How does this deanonymize the activities I do over Tor? The adversary still needs some other way to link my real identity to my anonymous or pseudonymous activities over Tor in order to deanonymize me.

You might argue that I may have been one of the few (or the only) person using Tor at the event. If the adversary could ascertain that the blog post was published via Tor, it would then be highly likely that I was its author. However, this relies on two aspects of the chosen example, either one of which could be independently sufficient for deanonymization without guard fingerprinting:

  1. I was using Tor in a place where not many others were (or no one else was). We already know, independently of guard fingerprinting, that this endangers anonymity. (Recall that in the case of the Harvard bomb threat several years ago, guard fingerprinting was not necessary to identify the one who sent the threat, since he was the only one using Tor from the network he used.)

  2. I used Tor to write about my real life public activities. An adversary can already correlate data about publicly observable events (e.g., the people in attendance) with writings published about those events regardless of guard fingerprinting. In fact, this has been happening for ages with no digital technology at all. Anyone who sees me at a public event knows that I could be the author of a piece written anonymously by someone in attendance. The fewer attendees, the higher the likelihood that it was me. This would, of course, be exacerbated by other clues. For example, if I had been the only person at the event taking notes with a pencil on a pad of paper, it would be fairly easy for an adversary to learn this from an eye witness and to infer that I was probably the one who published some piece of writing about the event. This is not new, and it is not unique to digital technology.

In summary, Tor Documentation for Whonix Users claims that guard reuse across physical locations can result in deanonymization, but it does not explain how this would occur, except to insinuate that it could occur in scenarios in which there is already a risk of deanonymization independent of guard reuse.

2 Likes
809

Thanks @adw. We can clarify that.

@Patrick

Please do a find & replace across wiki replacing:

<references/>

With:

{{reflist|close=1}}

This nicely puts all the footnotes into 2 columns, saving a lot of space for reading and printing. Plus it looks a lot better.

(You can see the difference in the bunch of pages I already did. Big improvement IMHO.)

1 Like
810

Error 503 Backend fetch failed

Backend fetch failed
Guru Meditation:

XID: 838205457

Varnish cache server
Impressum Datenschutz Haftungsausschluss

Immediately when trying to open “Release Notes” wiki page on v3 onion.

I’ve had another instantenous result like this is similar circumstances.

So, this is a new oddity that was not present over last 2+ years.

Again, immediate refresh of the page resolves correctly.

1 Like
811

Done!

Made edits throughout the chapter. Please let me know if any changes are needed.

Also, posted new screenshots for use with this chapter. Let me know if they’re OK and I’ll upload them to the sever. ( “Clone Qube” has many redactions).

https://forums.whonix.org/t/updated-screenshots-images-thread/5371/12

Introduction

Whonix is a secure operating system comprised of two virtual machines which are isolated both from each other and the host. This configuration averts many threats posed by malware, misbehaving applications, and user error. While Whonix protects against real world threats[ref]Read Security in Real World to see how Whonix protects against real world attacks[/ref], it still possible for an adversary with the proper skills to compromise Whonix-Workstation (anon-whonix Qubes-Whonix). Moreover, if only one Whonix-Workstation is used for anonymous activities, the attacker would have access to all data on the Whonix-Workstations and could monitor all online activity. To minimize the impact of compromise, users are encouraged to use muliple Whonix-Workstations to compartmentalize different identities and/or additional software. Depending on the users requirements, a second (or nth) Whonix-Workstation VM could be used.

Why use multiple Whonix-Workstations

Mulitple Whonix-Workstations can be used to run different torifed clients in isolated Whonix-Workstation VMs. By compartmentalizing each different identity or client, an attacker can read only the data in the compromised VM. For example, if Tor Browser in VM-1 was compromised it could not read your IRC identity in VM-2. However, keep in mind, if Tor inside the Whonix-Gateway or your host internet connection goes offline, all Whonix-Workstations will go offline. If multiple Tor clients were running simultaneously, an attacker could guess that you are the same person. For example, if two Tor users in one IRC channel go offline at the same moment.

Qubes-Whonix vs Non-Qubes-Whonix

When using multiple Whonix-Workstations, Qubes-Whonix is the recommended choice. This is because Qubes-Whonix is specifically designed for compartmentalization (a.k.a. sandboxing) within multiple running VMs. This gives Qubes-Whonix a significant advantage in both speed and security when compared to the traditional model of running multiple Virtual Machines within an existing OS (for example, running two VM’s under VirtualBox or KVM). For more information, see Why use Qubes over other Virtualizers.

Safety-precautions

While multiple Whonix-Workstations are recommended, it is safer to use only one Whonix-Workstation at any given time, and for a single activity.

Leaving multiple Whonix-Workstations running at the same time introduces new risks. If one of the Whonix-Workstation VMs was compromised, it can perform various attacks and not all of them can be defeated. Depending on the activities a user was performing in other Whonix-Workstations, a skilled adversary could correlate the various running Whonix-Workstations to the same pseudonym.

  • An adversary could stress either/and CPU, HDD, RAM, network connection and other Whonix-Workstations. It is possible the host could be negatively affected as well.
  • DDOSing:
    • Other Whonix-Workstations.
      • Non-Qubes-Whonix: There is no defense against DOSing other Whonix-Workstations.
      • Qubes-Whonix: Not applicable.
    • Whonix-Gateway
      • There is no defense.
  • Exploits:
    • This risk can be reduced by following the recommendations found in the System Hardening Checklist.
    • The adversary could try to exploit the Whonix-Gateway.
    • The adversary could try to exploit other Whonix-Workstations.
      • Non-Qubes-Whonix: Applies
      • Qubes-Whonix: Not applicable. [Unless Whonix-Gateway is compromised first.] (Details in chapter #Firewall.)
  • Workstation-Firewall:
    • Non-Qubes-Whonix: Whonix-Workstation provides an optional, disabled by default (because it can get into the way for other tasks) firewall, that can prevent different Whonix-Workstations from connecting to each other. (See Whonix-Workstation Firewall.) (Will be enabled by default in Whonix 14.)
    • Qubes-Whonix: Not required. (Details in chapter #Firewall.)
  • Impersonating
    • Non-Qubes-Whonix: A defense against impersonating (i.e. MITM or malicious gateway) other Whonix-Workstations or the Whonix-Gateway can be implemented using authentication, this is linked in the #How to use more than one Whonix-Workstation - More Security section below.
    • Qubes-Whonix: Not required. (Details in chapter #Firewall.)
  • Identity correlation through circuit sharing [ref]See Stream Isolation page for definition.[/ref]
    • Non-Qubes-Whonix: Is not at risk as long as the Whonix-Workstations aren’t compromised. Multiple Whonix-Workstations using different internal IP’s (as recommended in the instructions below) are automatically using Stream Isolation.[ref]Because How can we help? | Tor Project | Support IsolateClientAddr is Tor’s default.[/ref]
    • Qubes-Whonix: Not required. (Details in chapter #Firewall.)

How to use more than one Whonix-Workstation - EASY

Qubes-Whonix

Setting up additional Whonix-Workstations with Qubes-Whonix

Using multiple Whonix-Workstations with Qubes-Whonix is a simple process. To do this users can create an additional AppVM based upon the Whonix-Workstation template (commonly called whonix-ws) with its own distinctive name. After the new AppVM is created ensure that it uses sys-whonix as its NetVM.

Users can follow this link for step-by-step instructions on how to Create Whonix Workstation AppVMs.

Non-Qubes-Whonix

If you are interested in this with Non-Qubes-Whonix, please press on expand on the right.

Setting up additional Whonix-Workstations with download/default Whonix-Workstations

Non-Qubes-Whonix Only!

[noticebox]Note: The following instructions only apply for Download/Default-Whonix-Workstations or if you build it yourself from source code. If you would like to use an operating systems such as Windows, other Linux, BSD etc. please see the [[Other Operating Systems]] chapter instead.[end/noticebox]

Each additional Whonix-Workstation VM requires its own MAC address and internal LAN IP address.

1. Clone a fresh Whonix-Workstation VM.

VirtualBox

In VirtualBox Manager [clone#link] a clean Whonix-Workstation.

KVM

In Virtual Machine Manager clone a clean Whonix-Workstation.

Highlight Whonix-Workstation -> Open -> Virtual Machine -> Clone

2. Assign a new MAC address to the cloned VM.

[noticebox]Note: A new MAC address is also required if the additional VirtualBox VM is imported.[end/noticebox]

VirtualBox

In VirtualBox Manager assign a new MAC address:

VirtualBox -> Settings -> Network -> Adapter 1 -> Advanced -> Mac Address -> Create a new MAC address (press the green round arrow icon) -> Ok.

KVM

To change the internal network in KVM. See: Creating Multiple Internal Networks

3. In Whonix-Workstation. Open with root rights

/etc/network/interfaces.d/30_non-qubes-whonix

Change the last octet. For example 10.152.152.11 to 10.152.152.12

4. Save and Exit.

5. In Whonix-Workstation, reboot. Or alternately restart the network.

sudo service networking restart

6. Done.

How to use more than one Whonix-Workstation - More Security

  • Qubes-Whonix users: Can skip this. [ref]Because by Qubes default, AppVMs behind the same ProxyVM [or NetVM] are prevented from connecting to each other.[/ref]
  • Non-Qubes-Whonix users (everyone not using Qubes-Whonix): To prevent workstations from connecting to another one, see Whonix-Workstation Firewall. See also Connections between Whonix-Gateway and Whonix-Workstation.

Multiple Whonix-Gateways

Introduction

Advanced users only.

Multiple Whonix-Gateways can be used along side multiple Whonix-Workstations. However, this has both advantages and disadvantages. This set up is more secure since the Whonix-Gateway VMs are isolated from each other. In the event that one Whonix-Gateway is compromised, it is not certain the others will be compromised as well. However, the the newly cloned Whonix-Gateways will end up with a different set of Tor entry guards, unless you take precautions.[ref]Such as manually sharing your entry guards. Qube-Whonix users can Copy Tor State Files to Another sys-whonix Instance (Non-Qubes-Whonix no documentation ever written to my knowledge) or using the same Bridges[/ref]. Your ISP could guess that you are using two different Tor data folders, for whatever that’s worth. (If you are using multiple Tor Browsers, you end up with different sets of Tor entry guards as well.)

[noticebox]Note: Multiple Whonix-Gateways are easier to manage and more secure when a single Whonix-Gateway is used at at time.[end/noticebox]

Qubes-Whonix
Setting up additional Whonix-Gateway (commonly called sys-whonix) with Qubes-Whonix.

The only requirement for a newly created sys-whonix is it must be based on whonix-gw TemplateVM and given a distinctive VM name.

1. Create a new sys-whonix VM.

Users can create a new ProxyVM by following the step-by-step directions to Create Gateway ProxyVMs.

Non-Qubes-Whonix

If you are interested in this with, please press on expand on the right.

Introduction
When you are using them at the same time, the risks explained in the introduction chapter on this page apply.

Setting up additional Whonix-Workstations with download/default Whonix-Workstations

Non-Qubes-Whonix

VirtualBox
In this case, you also have to change Whonix-Gateway network interface2 and Whonix-Workstation network interface1 from internal network “Whonix” to something else.

KVM

See Multiple Whonix-Gateways.

Cloning Multiple Qubes-Whonix TemplateVMs

Cloning multiple Qubes-Whonix TemplateVMs provides much greater flexibility over a single template when choosing software packages. The additional cloned templates can be customized with software to meet specific requirements which would not be possible if a single TemplateVM was used.[ref]Users may also wish to clone the default template and use the clone as default template for AppVMS. This ensures availability of a “known-good” backup template.[/ref]

  • Packages from a later release - Installing packages from a later release could end up breaking the system. For example, mixing packages from Debian Stable with those from a later release like Debian Testing can lead to a destabilized system due to associated software dependencies required for full functionality.[ref]Using packages from different repositories can lead to Dependence Hell[/ref][ref]This problem can be avoided by cloning additional Whonix templates and preferring packages from a single repository in each TemplateVM.[/ref]Prior to installing Debian packages from later releases, first read #Install from Debian testing.

  • Custom software - With additional cloned templates users can install custom software used for a specific application. For example, users can Tunnel UDP over Tor by configuring whonix-ws to route all applications through a VPN tunnel. However, this method has the disadvantage of increasing the risk of identity correlation. To limit this risk, the AppVM based on this template should only be used for the particular application that a users needs to route through the tunnel-link.

  • Untrusted packages - Users should not install untrusted packages in a template used for sensitive activities. With multiple cloned TemplateVMs, a single template can be designated as a less trusted domain in which to install those packages.[ref]Users are strongly encouraged to install only signed packages from a trusted source.[/ref] Read: Notes on trusting your TemplateVM(s) prior to installing untrusted packages.

Cloning Qubes-Whonix TemplateVMs is very easy and can be done using Qubes Manager.

Qubes Manager-> whonix template -> Clone qube-> New name

2 Likes
812

A post was split to a new topic: Intermittent 503s reported by Varnish

813

This is because we have a non-obvious crucial unspoken assumptions here:
It’s realistic to assume that the IP address and flag “Tor use” gets logged by adversaries. This IP address is tied to personal data (real name, postal address, etc.) Most users use Tor from a connection signed up on their own name or at least someone close enough to them to identify them easily.

Key factors here:

  • proximity to event being reported
  • time of post being made (that very one Tor entry guard being in use from that very location to talk about that very event as it happened and then later someone using the very same Tor entry guard from another location using an ISP assigned (not Tor exit) IP address tied to personal information).
  • Tor entry guards being carried around in several networks

Yes. Tor is not super popular and even if it was, you’re probably still the only one using that Tor entry guard. The crowd to hide in being too small.

Indeed. Glad you mention it. We should document that.

Good point which is documentation worthy.

1 Like
814

Wasn’t part of this task however for future work:

  • Could you please briefly mention Qubes template implementation, i.e. that cloning of VMs and centralized updates are a lot a lot better usability in Qubes? Also this greatly saves time (for cloning) and disk space.

Cloning Multiple Qubes-Whonix TemplateVMs

Minor nit: → Multiple Qubes-Whonix TemplateVMs

Please add links to sections of Install Additional Software Safely

Overall this edit looks very good. Could be copied to wiki already as is with enhancements doable in later revision.

Could you please also explain what to do after cloning the TemplateVM? I.e. creating an anon-whonix-purpose based on that cloned TemplateVM? And pointing out that a separate TemplateVM needs to be updated separately?

815

Posting (larger) wiki edit suggestion to the forums first seems to create double work for the editor since discourse forums and mediawiki use different syntax. It’s also harder to see the actual diff.

If one is insecure about suggesting (complex) wiki edits straight to admin confirmation mediawiki queue… What about making a copy of that wiki page to a temporary wiki page? Then edits could be tested out there. And if good, these could be copied back to the original page after review.

2 Likes
816

Testing completed “comments to use Qubes onion repository”

(https://github.com/QubesOS/qubes-issues/issues/2623)

AFAICT these are the files that require comments # .

These files do not require comments. Because they pull from fedoraproject.org not qubes-os.org

If this is correct I’ll go ahead and make a pull request

Absolutely!

Ok

I’ll have everything complete by later tomorrow. :slight_smile:

Its a PITA :wink:

I thought posting here would make it easier for you and torjunkie to make remarks ( not having to copy and past from wiki to forum). Also I figured you may want to review some wiki edits remotely via forum e-mail (more convenient ?)

I’d be more than ecstatic to use a the wiki from now on :grin: :grinning:Yah!

I usually have the wiki chapter formatted ready to go (saved) before I post in this thread so this will make it a lot easier for me. Plus i typically use the bottom of wiki pages to see how the new edits will look. The temp wiki page will come in handy!

1 Like
817

Looks correct. I guess comments to use Qubes onion repository · Issue #2623 · QubesOS/qubes-issues · GitHub will be easily merged by Marek since it’s only comments from technical perspective so very very room to mess up things for most users / regressions. I interpret the silence in comments to use Qubes onion repository · Issue #2623 · QubesOS/qubes-issues · GitHub as non-controversy or perhaps low interest so probably ok.

818

0brand:

I thought posting here would make it easier for you and torjunkie to make remarks ( not having to copy and past from wiki to forum). Also I figured you may want to review some wiki edits remotely via forum e-mail (more convenient ?)

Well, remarks can be directly edited in once the initial version was
posted to the wiki. We don’t have a policy of “only near-perfect
versions may be published”. If it’s good enough, it’s good enough as
first iteration and enhancements are welcome. I guess that is more
productive.

Seldom (or never? I don’t recall) an initial version is so bad that it
would need a major revision before it could go live.

2 Likes
819

Thanks for the footnotes thing!

Additional request: need to replace <references /> as well

(note the space between s and /)

This is present on some pages and wasn’t replaced in the previous round.

That’s great content @0brand. Agree with Patrick, better to either:

a) Put it on an unpublished test wiki page as Patrick said if you want any major edits from others; or
b) Just put it straight into a page, Patrick will publish it, and we’ll nitpick it?

You know your stuff so shouldn’t hesistate too much in this regard i.e. don’t sell yourself short and start doing more of (b). :-))

2 Likes
820

Added to wiki along with

  • mention Qubes template implementation
  • explain what to do after cloning the TemplateVM

https://whonix.org/w/index.php?title=Multiple_Whonix-Workstations&oldid=35015&diff=cur

2 Likes
821

Qubes-Whonix 14 / Qubes R4 DisposableVM support is mostly undocumented.

I suggest to modify Qubes Disposables according to the following plan:

  • Whonix 13 DisposableVM: entirely unsupported
  • Qubes R3.2 Whonix 14: entirely unsupported
  • Qubes R4 Whonix 14: supported
1 Like