Moderating threads (Moving/ editing) does not always funtion properly.

[0brand]

@mig5

I’ve noticed over that past week or so that I am not always able to move/edit posts. When editing posts on two separate occasions I was prompted with a message stating something to the affect of - This post had been edited by another user since i had started editing - which wasn’t true, and I was unable to push my edits.

When moving posts I’m not always able to press the blue button after selecting the thread I’m moving the post to. It seems like some of the graphics are not rendering even when Tor security setting is on standard ( low) and Java script enabled.

And I believe @torjunkie recently had an issue with editing a post?

Possible this is from upgrading the forum software?

[0brand]

This is what it looks like when I have trouble moving a post. The blue button is actually hidden behind other text. Not a problem with graphics rendering. When trying to hit the button I end up inadvertently selecting a different thread.

After experimenting for a while I found that enclosing the text in quotes " " narrows the list down to where it does not hide the blue button.

“Long wiki edits thread”

[mig5]

Thanks @0brand, I did do a Discourse update recently, so that could be the cause. It looks like a styling/theme issue so I don’t think other causes such as Content-Security-Policy etc would explain inability to click a button.

It’s a bit tricky to debug intermittent issues like the edit one - I still wonder if that was legitimate e.g the post was edited in some small way… - or, it sounds like it could be a session issue…

I will try and reproduce and debug further, and I’ll also look upstream to see if anyone else has reported the issue, or if there’s even a new release with a fix already.

[mig5]

Hi 0brand, I reproduced the issue re: moving post to existing thread. I am pretty sure it’s an upstream bug so I’ve reported it at https://meta.discourse.org/t/moving-post-to-existing-topic-causes-theme-overlap-button-cant-be-pressed/102290

We’ll see what the developers think. Thanks.

Let me know if you reproduce the ‘edit post already been edited’ issue and if you can grab a screenshot or the exact error message (may help when searching reports upstream). I haven’t reproduced that one myself.

[mig5]

@0brand, upstream confirmed the ‘move to existing thread’ overlapping button issue was a bug and that a fix has been committed. I forced an upgrade to include the fix and I confirm that the bug looks fixed now. Thanks for bringing it to my attention.

Cheers

[torjunkie]

FYI

Couldn’t login to either v2 or v3 onion just now. So, either some discourse problem over .onions or an attack I presume.

Kept dropping back to forums.whonix.org

[mig5]

I reproduce this. After login, there is a redirect back to the ‘main’ URL. I guess this is a new ‘feature’ introduced as part of the upgrade I did to solve the issue above. What fun.

Most apps - particularly popular, and complex ones, like Discourse - are pretty hostile to the idea of .onion. I don’t think I’ll be able to fix - even if I do clever things in Nginx to bounce back to .onion, there’ll probably still be that redirect away to the ‘clear net’ first.

If I get time (rather, if @Patrick wants me to spend time on it) I will look into the Discourse commits to see when/how it was introduced and whether we could convince upstream to change it back, but don’t like my chances, and Patrick would probably prefer it deprioritised.

Sorry guys, quite annoying indeed!

[mig5]

I think I found the root cause

SECURITY: enforce hostname to match discourse hostname

I posted upstream about it. I appear to have a history of having my posts deleted when I ask for help, or get sassy replies implying a disregard for ‘niche’ cases like Tor, so I have little hope this time will be any different.

Forcing hostname has broken support for Onion Services

[torjunkie]

Thanks mig5.

I see they are going to make an issue of it. Commentator #3 is wrong, since:

1. Whonix offers both clearnet and .onion for fallback option if onion goes down.
2. Whonix server is not actually trying to be anonymous, but by offering .onion, users have a higher encryption standard i.e. relying on onion encryption itself instead of probably backdoored encryption certificates from dodgy-as-hell providers.
3. Probably much harder for observers to screw with / monitor activity by solely remaining in Tor network.

So, they should just provide a simple whitelist option like you said.

(Edit to remove rant)

How hard would it actually be in programming terms, since the logic is quite simple i.e.

IF user-generated whitelist has “X .onion domain”

THEN Don’t run the enforced hostname clearnet option, at section Y.

[torjunkie]

@Patrick

As this is clearly going to be unresolved for the forseeable future, I think we should explicitly warn users.

(Indeed, I am tempted to not use forums at all anymore, even though I know I and any other Whonix team members are highly likely to have been identified long ago by the State due to breaking basic protocols like using long term handles. Fortunately, my locale won’t imprison me for having the temerity to do so - other Whonix/Tor users can’t say the same)

The Whonix forums were previously accessible via either the v2 or v3 onion, but due to recent Discourse changes outside of our control, attempts to login will fall back to the clearnet host address - www.forums.whonix.org

As a consequence:

• Users will no longer remain solely within the Tor network i.e. a clearnet exit node will be used - increasing the likelihood of end-to-end correlation (and other) attacks.
• Users will no longer benefit from the higher onion encryption standard, since clearnet connections are dependent on encryption certificates issued by Certificate Authorities (CAs). As CAs have been frequently attacked in the recent past, this increases the chance of successful, targeted attacks on Whonix users by advanced adversaries.

For high-risk users, it is recommended to only create short-term handles for forum purposes. These should only be used for a strictly limited period, in order to reduce the attendant de-anonymization risk.

Until this issue is resolved in Discourse (unlikely; the have deemed it to be a ‘niche’ issue) or an alternative platform is identified, users should not expect absolute anonymity when using the forums. If possible, do not use the forums at all if the required information can be found via a wiki, forum or broader Internet search.

[0brand]

attempts to login will fall back to the clearnet host address

Forcing .onion can be used as a temporary mitigation. If using Qubes/DispVMs a DVM template can be customized specifically for Whonix forum with user rule sets. Downside to this is fingerprinting.

https://whonix.org/wiki/Forcing_.onion_on_Whonix.org#Adding_User_Rules

[torjunkie]

Well, hopefully that works.

If it doesn’t, then my collaboration here is finished, and someone else can spend another 2 - 2.5 years to finish off a full documentation edit. Simple.

[mig5]

A Discourse contributor has provided an example solution via means of a custom plugin

I’m leaving the link here in case the upstream thread gets deleted on me (again).

patch enforce hostname to allow blog as well

I haven’t tested it yet, it’s just a note for me/us later if we want to try it.

(P.S don’t worry, I am ‘volunteering’ this info, not charging for it )

I haven’t tried the HTTPSEverywhere solution either, but yes in theory that should work, since the browser will receive a 30X redirect to the clearnet domain, but the browser will then rewrite the subsequent request back to .onion before sending it.

Hopefully you don’t end up with a redirect loop, and hopefully you have a valid session still as opposed to be logged out… I’d be interested to hear if it worked.

And yes, I tried to politely note in the upstream thread that the response had overlooked several features of .onion as well as the fact that hitting clearnet over Tor introduces the risk of malicious exit nodes if not other issues… meh

[Patrick]

I think this might be resting on several invalid assumptions:

• whonix.org server somehow being super secure, not being affected by most if not all data centers being compromised with both, back- and frontdoor.
• Whonix onion being more than an experimental gimmick.
• whonix.org somehow providing stronger protections than what the software Whonix can provide.

I am sorry if I made mistakes that created any of these impressions. Let me know how this happened.

whonix.org:

• Not even Qubes based (since Qubes server support is very, very limited).
• Javascript required at very least for forums.
• I guess for sure less safe than let’s say facebook.com from compromise from random attackers since they can afford self-compiled, hardened packages, a teams of full time sys admins, honeypots, IDS, IPS, whatnot. One can provider Whonix has a hobby or secure a webserver as much as possible as a hobby but not both at the same time. whonix.org is only the means to provide Whonix.

This seems to also assume that there are various levels of risks:

• risk level 1: risks of using Tor (and or of using Tor/Whonix)
• accelerated risk level 2: contributing to Whonix (and or Tor/Whonix)

I am not sure it’s speculative? We can theorize but we could also theorize that surveilled torified but non-onion connections to whonix.org (this seems to be the basic assumption) are better than connections to onions. At least connection to whonix.org aren’t planning for world domination, and the “known bad” (whonix.org) is better than the unknown unknown (first/few/only real secret, “real secret onion connection”)?

Since a secret whonix.org sever compromised should be assumed (as any server should be considered compromised) I see great risks from Stylometry and Keystroke Deanonymization. Problems without good answers.

[0brand]

Hopefully you don’t end up with a redirect loop, and hopefully you have a valid session still as opposed to be logged out… I’d be interested to hear if it worked.

I’ve had no problems. Actually, I’ve been using HttpsEverywhere rulesets for the Whonix forums all along so I wasn’t even aware of the issue until torjunkie brought it up. Apart from the increased risk of fingerprint it made sense to use the HttpsEverywere rulesets because I often use search engines when answering support requests. Sometime if find the answer by clicking on a link that takes me back to the forum thread. Wanted to make sure I always stayed on the Whonix .onion.

[kasuvus]

whonix.org is only the means to provide Whonix.

It’s much more than that. It’s also the means to learn how to use Whonix correctly and further solve technical issues that arise.

Just imagine you removed all content from the server except the files that are required for downloading Whonix. You can expect Whonix users number to go down really fast.

[kasuvus]

I see great risks from Stylometry and Keystroke Deanonymization. Problems without good answers.

At least Kestroke Deanonymization and other fingerprinting techniques will be solved or become less effective when we move to a non-js forum.

[0brand]

Hopefully you don’t end up with a redirect loop, and hopefully you have a valid session still as opposed to be logged out… I’d be interested to hear if it worked.

I’ve had no problems.

Started to have intermittent issues with NoScript. Sometimes I have to select the option to resend site data to continue with login. There have been a couple times where this didn’t work and had to start login over again. Still better than nothing IMO.

Edit: To be clear I assume that this behavior is caused by the Discourse Forcing hostname patch.

[mig5]

@0brand @torjunkie just an FYI that I was bored so I wrote a plugin to allow staying on the .onion. I no longer get booted back to the clearnet domain when logging in via onion.

Let me know if all good for you now. If so I’ll make the plugin ‘stick’ across future upgrades (probably will enhance it a bit and make a github repo for it)

[0brand]

Let me know if all good for you now.

Thanks for working on this! No longer having problems with redirects from .onion to clearnet during login .