Advanced security guide:
Experiment with these…
Added to Top of my list along with
document multiple Qubes TemplateVMs:
wink, nudge, nudge @torjunkie 
1 Like
Thanks @0brand - linked all your pics and edited Screenshots accordingly. Pity about success message, I thought it stayed there until closed by user (or it used to).
ha ha - I’ll let you work your technical magic and come sniffing later on 
Bump @Patrick
If you approve all that, it will be much easier to start fixing all the links from the 3 splits.
Plus, it improves the main ToC which is too chunky in that section I split into browsing, email & messengers, other anonymous services. (plus splitting off dev/license stuff into own section)
1 Like
Please close.
torjunkie:
Bump @Patrick
If you approve all that, it will be much easier to start fixing all the links from the 3 splits.
Plus, it improves the main ToC which is too chunky in that section I split into browsing, email & messengers, other anonymous services.
Sure. Thanks for letting me know that this blocks things so I will
prioritize it. (Previously I didn’t prioritize since it looked like a
time consuming change.)
Unfortunately the accept revision button is broken perhaps due to recent
changes. Already notified mig5. I’ll review as soon I hear it’s repaired.
1 Like
Revision button should be fixed now! 
3 Likes
Amazingly quick! Thanks for being so proactive
I have another one for you:
When editing the wiki, I saw this error, which I’ve never encountered before:
Error 503 Backend fetch failed
Backend fetch failed
Guru Meditation:XID: 543227909
Varnish cache server
Subsequent edits worked after refreshing the page.
Might be related to recent tightening of server config.
1 Like
Hi @torjunkie, thanks for the report…
Do you happen to know what time you saw this error (maybe UTC or CEST would be useful, to correlate with server time which is CEST, but whatever works for you if you can specify the timezone).
And/or what page you were editing at the time.
A 503 reported by Varnish means it couldn’t get a response from its backend Apache, which is a surprise to me, as that’s an area I didn’t touch recently (and I’ve touched a lot of areas! )
One theory is the logrotate daily cron or something reloaded Apache at just that precise time (e.g a fluke) but knowing what time you experienced this will be useful. Unfortunately Varnish doesn’t really log anything so it’s hard to debug further.
A 503 would also occur if some sort of timeout threshold was tripped between Varnish waiting for Apache to respond - e.g if you’re uploading a very large file that might occur. So a bit of context might help track this down, so far not seeing much in the logs other than a 503 on the ‘Screenshots’ wiki page at 10:11AM CEST or so…
2 Likes
Hi mig5,
Yes, that was me. I guess it was just a fluke(?) in timing.
Thanks for the education you’re giving everyone too in explaining things, it’s appreciated.
BTW phabricator used to be the real buggy Whonix sub-domain, often reporting some “clustered(?) exception error” (I think), and a refresh was required for the page to present properly.
But it seems fine recently, so fingers crossed.
2 Likes
@torjunkie yeah, the Phabricator issue was due to ‘too many connections’ MySQL errors - a side-effect of its peculiar database design - and we recently saw it even impacts the wiki since they share the same MySQL server. Both issues should not reoccur
The Varnish one remains a mystery, might need to add some logging and attempt to reproduce some other time. Curious if it was instantaneous or whether there was a long timeout first. Anyway, let me know if it occurs again.
2 Likes
That was instantaneous after either hitting the “edit” or “preview” button.
1 Like
OpenPGP Best Practices - riseup.net is nice although they recommend 3072 RSA which I see no reason for if we can easily use maximum key length 4096 RSA.
1 Like
I’m holding off on edits until the main ToC page is approved i.e. as this prevents me finishing off recent weeks of work (and satisifying my editing OCD). 
1 Like
Whonix ™ Documentation already is confirmed. It doesn’t show any edits. Permission error - Whonix also doesn’t list it.
Pending approval:
Really strange. Since not shown anywhere. Check if done now please.
1 Like
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
My answer:
[…]
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
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