Forum login over the .onion endpoint as of several days ago and today (2024-12-23) fails with “Unknown error” response. Clearnet works fine.
POST request to the /session endpoint has response code 403 with raw body of ["BAD CSRF"] despite the X-CSRF-Token header having been included in the request.
Confirmed.
It might stay broken for a long time.
Discourse upstream does not mind much about Tor / Tor Browser:
Multiple domain names are unsupported:
Developer information.
Discourse introduced this issue in version 3.3.3. (Commits · discourse/discourse · GitHub)
Unfortunate.
However the Tor Project forum also uses Discourse and a similar “dual-stack” configuration (accessible by a clearnet and .onion endpoint) and I was unable to reproduce this issue so I checked using these instructions and it appears to be running a newer beta build of Discourse. So if that is the case I would be curious of the exact difference.
Considering forum.torproject.org has functional login with both endpoints using a recent version of Discourse, do you think it might be worth asking how it is configured or attempt to reproduce its configuration locally for testing in attempting to investigate and fix this issue?
Please ask a general question how they set that up.
No need to mention Whonix.
Actually, no need to ask just yet.
It’s described here:
https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/forum#onion-service
It requires either disabling force_https (supposedly) or TLS certificate for the onion domain. These are both not great solutions. A better solution might be to conditionally disable force_https on the onion domain in our plugin (linked above).
There is another potential solution:
That is a necessary condition to get dual domain support at all. But that does not invalidate the following.
Internally, Discourse has a
force_httpssetting which determines whether links are generated using thehttporhttpsscheme, and affects CSP URLs. When this is enabled, the forum does not work using the onion service because CSP URLs in the headers sent by Discourse are generated with thehttpsscheme. When the parameter is disabled, the main issue is that the links in notifications all use thehttpscheme.So the most straightforward fix is simply to serve the forum via
httpson the onion service, that way we can leave theforce_httpssetting enabled, and the CSP headers don’t prevent forum pages from loading.
We do have dual domain support already but the way browsers treat “secure cookies only on HTTPS” (which discourse enabled) is breaking this because the browser does not consider the onion to be “really, fully” HTTPS.
Okay, so what is the problem with issuing a TLS certificate for the .onion domain name?
Additional server maintenance workload, including:
Let me interrupt you here. Not a useful comparison. The Tor Project is an organization with:
[1] 2024 12 02 · Wiki · The Tor Project / TPA / TPA team · GitLab
[2] https://www.torproject.org/static/findoc/2021-2022-The_Tor_Project-AuditedFinancialStatements.pdf
Would you prefer that I continue providing practical suggestions and problem solving this and other issues on the Whonix Forum, especially within the Qubes-Whonix category, or continue attempting to predict responses I cannot justify generating and needlessly waste both of our resources?
With a view towards investigation and resolution of this issue are there any suggestions as for next steps? As previously observed a “real” certificate for .onion https support is an additional complication best avoided.
If need be. I could possibly setup a private Discourse test instance in attempting to resolve this issue by plugin or similar mechanism.
If you can create a plugin or documentation to fix this then that would probably help why not by all means please help fixing this.
Yes, if someone can explain how to do this speaking from experience, that would help. A pull request against our plugin would be appreciated if that is possible.
Yes:
; you should set them up only for your own sites, or for sites which do not require login credentials of any kind.
But forums require login credentials. So that as far as I can see won’t work.
It can work:
Do they have a discourse forums?
No, but login credentials are required for subscribers to post opinion pieces within the Mediapart Club:
After English translation using my Mozhi instance with the Google Translate engine:
It’s not any login that’s the general issue. The existing implementation has worked for years. What changed is that discourse is specifically picky at the application level. Probably cookie attribute secure, which enforces https only or something similar. This issue fortunately does not exist for MediaWiki, where login is still functional.
When controlling the webapp (a web developer taking directions from the domain owner) (presumably the case for these websites), this is easy to fix by telling them to not enforce these https-only features on the non-https onion domain.
When not controlling the webapp (independent Open Source project, with many people wanting, paying for different features) (discourse), that does not care about dual domain / optional onion domain support, this gets much harder.