A dedicated page with dedicated maintainer would be ok. Then Whonix is
more like a third party host of information and we have limited duty to
review the contents.
These contents are inspiring for sure for some readers but seems non-essential for most users of the warning page. However, this goes more into the direction of a research project. It would a lot time to get knowledgeable enough to be capable to review and publish it for me.
As chapter License of the Warning page indicates, the Warning page was initially based on Tails Warning page. So any argument made by me just now could be turned against me. Such inconsistencies would be inherited from the fact that this was initially a fork of Tails documentation for completeness of Whonix documentation sake rather than a well thought through “what the user really needs” (which is an afterthought much later now).
I think @HulaHoop has a point here. the issue of online security is huge and perhaps it will be useful to separate the attacks we can mitigate from those we can’t.
Specifically, what’s missing for me is a more Whonix-centered threats page, and practical ways to address them, if any. For example:
- Effect of sdwdate or whonixcheck on possible classification as a Whonix user vs. any other Tor users (by Guard?).
- Workstation to gateway flow of info. For a careful user, the workstation is “what you do” while the gateway is “who you are”. The combination of both presents the biggest danger. But when the info from the workstation isn’t encrypted, gateway has both “who you are” and “what you do”. Is there a way to address that.
2 Likes
No problem. Just get rid of them.
1 Like
Covered here:
?
Looks so. Another point - can the UTC settings in Whonix be a giveaway?
Tor browser presents UTC anyway. If somehow the Guest time is exposed (if not possible with TBB, then say with FF), this info can be used.
For example, a clearnet site in Russian observes the following:
- User accesses it at hours that makes sense for people in Russian timezone
- User arrives through a Tor exit relay
- Browser exposes the OS timezone is UTC
What’s the likelihood it’s a Whonix user? Similarly for an Australian or Japanese site? or a site that mainly relevant for Pacific time users?
Tor Entry Guards: Difference between revisions - Whonix
I don’t think these instructions lead to different Tor entry guards.
Making a snapshot of Whonix-Gateway after it boostrapped results in Tor having already picked its entry guards. Reverting to such a state always ends up with the same Tor entry guards.
The most usable way to do this might be multiple Whonix-Gateway’s.
Manually copying Tor guard configuration each time before each use case seems error prone and complicated.
# This snapshot should be used with <u>all</u> 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.
Not sure about this also.
//cc @HulaHoop
How’s it so if Tor was not started yet?
We want the same guard for all activity of the same type. To run two email accounts concurrently, then you would need to clone the GW.
You’d never need to do this. Just use the same GW snapshot or clone.
Quote Tor Entry Guards: Difference between revisions - Whonix
# Start Whonix-Gateway and wait for Tor to finish bootstrapping (connecting).
Finish bootstrapping = Tor has chosen its entry guards.
Quote Tor Entry Guards: Difference between revisions - Whonix
Whonix-Workstation snapshots related to/called “Email”, whether it is identity “John Doe”, “Jane Doe” and so on.
This sounds like multiple e-mail accounts should be using the same Tor entry guards.
Well that text did say to create these snapshots per domain of activity i.e. Email, IRC etc. and not for separate identities within a domain e.g. Jane Doe 1, Jane Doe 2 etc.
2 Likes
My first point is obsolete. I didn’t read:
# Take a snapshot and name it “Original”.
Well, if you made the revision, then this issue was inherited. I can see the original is unclear on that. Happy that it gets more visible now so we can clarify. 
Should we have
- another Tor entry guard per application “only”, OR
- another Tor entry guard per application and identity?
I can’t see how one could hold the position 1) while at the same time arguing against 2).
This snapshot should be used with <u>all</u> Whonix-Workstation snapshots related to/called “Email”, whether it is identity “John Doe”, “Jane Doe” and so on.
Could you please rewrite that one? E-mail for John Doe and Jane Doe should be using different entry guards.
Note the Workstations should also be generated separately from a clean baseline.
clean baseline may be unclear for readers. Users will wonder what’s clean, what’s dirty and what’s baseline. (Also inherited issue; just while we are at it.)
Transporting UDP Tunnels over Tor: Difference between revisions - Whonix
| If/when the VPN connection breaks down, direct Tor connections are made without the VPN.
Could you mention the fail closed mechanism please?
If the VPN/SSH server is adversary-controlled, Tor protection is weakened. [7]
Could you please elaborate with a quote or explanation?
Website Traffic Fingerprinting
VPN and SSH protocols are vulnerable to website traffic fingerprinting: [8]
Could you please put in context? In context of Tunnel UDP over Tor - Whonix it would mean, that the Tor exit relay could apply “website traffic fingerprinting” and then see - even though the user is using a VPN/SSH - which website the user is visiting. That may be quite minor in this context?
In another context, when the user is using only a VPN/SSH without Tor, “website traffic fingerprinting” seems a lot more impressive.
Background: TorPlusVPN · Wiki · Legacy / Trac · GitLab was written by me years ago. There is “website traffic fingerprinting”. Research papers show that which website is being visited but not what exact contents are transmitted is still visible when using VPN/SSH and perhaps (years ago?) even to a degree against Tor (this might be improved/fixed by now). I’ve made the argument there if “website traffic fingerprinting” is possible, then detecting Tor inside a VPN/SSH should be a piece of cake. While that’s not directly proven, it sounds convincing and no one ever challenged that.
Another nitpick: Tunnel UDP over Tor - Whonix talks about tunnels, but then the table talks about VPNs.
But I see due to the different contexts:
- comparison with clearnet [1]
- pre-Tor
- post-Tor
a wiki template may be difficult.
No they must use the same entry guard since both are e-mail related activities.
But why? Can’t the argument made to use a separate Tor entry guards per activity be used to argue for separate Tor entry guards per identity or identity and activity?
We’ve been preaching stream isolation and now we’ll suggest to merge streams for different identities because they’re part of a similar activity.
So if it was instant messengering or a different e-mail (alike) client like bitmessage and a different identity, we’d suggest to isolate the streams but since it happens to be in a new category of activity, the streams should be merged?
Would still be handy to have.
1 Like
That’s to limit the amount of damage a particular app can expose you too if a guard is malicious. Tariq’s calculations deem that this is the safer way as opposed to running a different workstation for each identity with its own set of apps and guard.
Stream isolation is a great failsafe in case a user mistakenly signs on with an account on say, thunderbird, linked to his real identity while running other traffic. The main point of stream isolation is to prevent the Tor Exit from linking activities, not to protect from a bad acting guard. However in the scheme of protecting from malicious guards the 1 Guard/ 1 app technique was seen as best.
Isolating streams does not change the guards AFAICT so its not enough in this case. To keep in line with the advice, a user would need to run the IM within it’s own VM and guard node and Bitmessage with its own set. Whether a different identity or not.
1 Like
Btw yes, we are still using the AOS moniker.
Quote Whonix - Overview
Privacy protection. Anonymity online. Anonymous Operating System.
But there is no reason to stick with anything forever just because it was used for a long time already. Once others started copying this and calling us that way (which has happen by now), for outreach purposes we can change our moniker / slogans from time to time, perhaps with SEO in mind.