Most web applications expect to be at one location (domain.tld/folder) or (sudomain.domain.tld). I’m not sure if this is for performance reasons or most devs are lazy, but that’s simply the way it is. Our HTTPS Everywhere hack is the best solution we have at the moment.
has anyone else been having issues with the forum on the onion? i get nothing but the menu bar once javascript is enabled.
Accessing the forums from the onion link shows the category tabs at the top but nothing else loads. The same happens at all TBB security levels.
2 Likes
Won’t fix.
(Lack of resources / time.)
1 Like
Fixed. Works for me now. Posting this over onion.
There are still various glitches which I cannot fix. For example Whonix logo is not shown in left corner.
These are the same issues as explained here: Uploaded Images doesnt show up after creating topic - #3 by mig5
Content Security Policy: The page’s settings blocked the loading of a resource at http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqp…vjwsyd.onion/t/onion-forum-site-redirects-to-clearnet/197/12 (“base-uri”).
Content Security Policy: The page’s settings blocked the loading of a resource at https://forums.whonix.org/uploads/default/optimized/2X/f/f75358a50c52ba88d6c2e29e16841d4e8c0bc01d_2_32x32.ico (“img-src”).
Content Security Policy: The page’s settings blocked the loading of a resource at https://forums.whonix.org/uploads/default/optimized/2X/1/1fe0587524112f37ca32e0541d281d3d0a4eedf9_2_180x180.png (“img-src”).
Content Security Policy: The page’s settings blocked the loading of a resource at http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqp…vjwsyd.onion/t/onion-forum-site-redirects-to-clearnet/197/12 (“base-uri”).
Actually I found a way to hack around these issues. Should now be fixed. Let me know if there are still any Whonix onion forums issues.
1 Like
Great - works.
This begs the question:
- Is it time to link back to the v3 onion Whonix forum by default here: file:///usr/share/homepage/whonix-welcome-page/whonix.html
- If no to point 1, how about using the HTTP header option so users are notified of the onion option when they come to the clearnet version of the forum? Better protection for users.
Onion Location
Website publishers now can advertise their onion service to Tor users by adding an HTTP header. When visiting a website that has both an .onion address and Onion Location enabled via Tor Browser, users will be prompted about the onion service version of the site and will be asked to opt-in to upgrade to the onion service on their first use.
- All this reminds me, is it also time to revisit v3 onion Whonix repositories by default now that OnionBalance supports v3?
https://onionbalance.readthedocs.io/en/latest/v3/tutorial-v3.html
[1]
Not sure onion v3 can handle the load.
Related, just now asked:
[tor-dev] onionbalance useful on same server / for high-spec non-location hidden servers?
Whonix isn’t a web server / web service project. It’s a means to an end. Not an end in itself. More elaboration on that:
Trusting the Whonix ™ Website
Then also due to other issues mentioned on Trusting the Whonix ™ Website the impact might be low compared to other TODO.
Therefore perhaps too low priority to spend time on that. Not sure yet.
It’s a really cool feature. I’ll try to get that. But before, other broken aspects of Whonix onion need to be fixed. Most importantly, wiki editing over onion.
Found a promising approach for that now finally.
Two domain for one installation on Project:Support desk
Not sure we have a dedicated forum thread for Whonix onion wiki but will search and update once I know more.
Similar as [1]. Onionbalance v3 seems non-trivial to setup. A high traffic onion server sadly isn’t a side project. I haven’t seen any comparable (such as Debian or Tor Project onion v3) repository yet or how they’d set that up. Sadly isn’t a side project to have load balanced onion v3 backed by multiple servers / multiple Tor instances.
1 Like
Got a very informative reply:
https://lists.torproject.org/pipermail/tor-dev/2020-June/014347.html
1 Like
This has been implemented on whole whonix.org (homepage, wiki, forums, phabricator, deb). 
Most website components should work quite well except minor imperfections such as a missing onion forums (onebox) image here and there. Please test.
It got better. But not yet perfect. Login over onion is now possible. Server side, invented this:
<?php
if (preg_match("/dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/i", $_SERVER['SERVER_NAME'])) {
$wgServer = '//www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion';
$wgCanonicalServer = 'http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion';
$wgAllowExternalImagesFrom = array( 'http://127.0.0.1/', 'http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/' );
$wgRenderHashAppend = "www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion";
$wgCachePrefix = "www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion";
$wgFileCacheDirectory = "$IP/cache/www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion";
$wgLocalisationUpdateDirectory = "$IP/cache/www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion";
$wgCacheDirectory = "$IP/cache/www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion";
} else {
$wgServer = '//www.whonix.org';
$wgCanonicalServer = 'https://www.whonix.org';
$wgAllowExternalImagesFrom = array( 'http://127.0.0.1/', 'https://www.whonix.org/' );
$wgRenderHashAppend = "www.whonix.org";
$wgCachePrefix = "www.whonix.org";
$wgFileCacheDirectory = "$IP/cache/www.whonix.org";
$wgLocalisationUpdateDirectory = "$IP/cache/www.whonix.org";
$wgCacheDirectory = "$IP/cache/www.whonix.org";
}
But parts are still broken. Editing over onion still briefly redirects to non-onion when saving. Will try to fix.
EDIT:
Improved version:
<?php
## avoid error:
## PHP Notice: Undefined index: SERVER_NAME in /etc/apache2/server.php on line 5
## when using:
## php /var/www/w/maintenance/dumpUploads.php --base "/"
if (!isset($_SERVER['SERVER_NAME'])) {
$_SERVER['SERVER_NAME'] = $_SERVER['SERVER_NAME'] ?? 'www.whonix.org';
}
if (preg_match("/dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/i", $_SERVER['SERVER_NAME'])) {
$wgServer = '//www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion';
$wgCanonicalServer = 'https://www.whonix.org';
$wgAllowExternalImagesFrom = array( 'http://127.0.0.1/', 'http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/' );
$wgRenderHashAppend = "www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion";
$wgCachePrefix = "www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion";
$wgFileCacheDirectory = "$IP/cache/www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion";
$wgLocalisationUpdateDirectory = "$IP/cache/www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion";
$wgCacheDirectory = "$IP/cache/www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion";
} else {
$wgServer = '//www.whonix.org';
$wgCanonicalServer = 'https://www.whonix.org';
$wgAllowExternalImagesFrom = array( 'http://127.0.0.1/', 'https://www.whonix.org/' );
$wgRenderHashAppend = "www.whonix.org";
$wgCachePrefix = "www.whonix.org";
$wgFileCacheDirectory = "$IP/cache/www.whonix.org";
$wgLocalisationUpdateDirectory = "$IP/cache/www.whonix.org";
$wgCacheDirectory = "$IP/cache/www.whonix.org";
}
EDIT 2:
1 Like
Very nice! Well done 
Seems to work well on phabricator, forum etc.
1 Like
Fixed. All components of Whonix website should now have full onion support as far as functionality goes. Usual onion issues (slow speed, overload) might still happen.
This is now fully implemented.
1 Like
Seo links cannot point to clearnet.
Documentation: Difference between revisions - Whonix
Generally, please don’t add onion links to any websites anywhere on whonix.org. There can be exceptions when sensible. (Such as if we were to link to a website that is exclusively available over onion.) In case of Whonix wiki it’s still just 1 wiki database which is “in synchronization” [1] between clearnet domain and onion domain. By adding an onion link [when editing Whonix wiki over onion] that edit will also apply to the clearnet version of Whonix wiki.
(There are some unfixeable caching issues but a manual or perhaps later automated cache clear could fix that.)
I didn’t make any manual changes to the images on any of those pages (nor those today).
It appears whatever website changes you’ve made very recently to enforce onion connections (and stop fallback to clearnet even momentarily) has had the unintended side effect of causing any edited page to immediately appear with the .onion image in the Editing Pane view in that section. It didn’t happen a week ago.
Test it for yourself and see. I must admit it is a weird side effect.
PS hiding “Recent Changes” from people not logged in is annoying for editors. Although I gather it probably has various protective benefits re: unfriendly network observers.
1 Like
Definitely some problem with the editing pane. Every single instance of https://whonix.org is replaced with the Whonix v3 onion equivalent automatically, without any interaction from the editor.
Even if you try to change it back to https://whonix.org, when you preview the change it is still the .onion equivalent. Weird. For example, see the Forums page where I inserted one line only - a thumbnail image of the Whonix forums.
In the same edit, the editing pane automatically changes around 4-5 links to the v3 onion, without interaction…
1 Like
Good to know.
Indeed. I disabled the auto replacement of clearnet links to onion for now. Unfortunately that went both ways, inside the html (GET) and inside the user submissions (wiki edit, POST).
Until I find a fix for that might have less perfect onion support now (more links to clearnet such as top bar HOME link to clearnet rather than onion) but major functions (editing over onion without redirect to clearnet) should still working. Please try.
Homepage images on onion are now broken but I will fix that shortly.
Does not happen for me in a fresh Tor Browser. And probably doesn’t happen for you in a fresh Tor Browser too. It would however happen in a browser where one has set.
Being purely technical here, ignoring usability issues: I did no such thing. The only thing I did is implement the HTTP header feature which support for was added in Tor Browser 9.5 Onion-Location.
Some technical details:
- server provides a pure informational offer:
Onion-Locationcan be found at[...].onion. - server does not detect who visits from Tor network and who does not
- server does not force redirect clearnet connections to onion in any case
- What the browser does when it sees the
Onion-LocationHTTP header (laymen: “an offer”)
Try Onion Services
There’s a more private and secure version of this site available over the Tor network via onion services. Onion services help website publishers and their visitors defeat surveillance and censorship.
Learn more…
Not Now | Always Prioritize Onions
If you want to upgrade only one time, click “Not Now”, then press again on the “Onion Available” button. However, if you choose Always Prioritize Onions then the browser will force the user each time a clearnet server shows the Onion-Location offer to use the onion instead. It’s a browser feature.
In browser URL bar go to about:preferences#privacy
switch from
Onion Services
Prioritize .onion sites when known. Learn more…
Always
Ask every time
to [x] Ask every time.
Btw since this is a server side feature, Forcing Onion Connections on whonix.org does still make sense since onion location is better enforced client side.
No security/performance benefits
Could you document that please?
Reason: Server is getting hammered by 100’s of crawling and vulnerability scanning bots causing an guesstimate of 30-60% of traffic. Most probably non-targeted attacks. These download every revision of every page and compare every revision with revert revision, maximum out all permutations which are virtually endless.
Non-reason: hiding history from public.
Reference to see how many bots are out there:
- nginx-ultimate-bad-bot-blocker/_generator_lists/bad-user-agents.list at master · mitchellkrogza/nginx-ultimate-bad-bot-blocker · GitHub
- https://www.imperva.com/resources/resource-library/reports/2020-bad-bot-report/
Potential improvement:
What I could do instead is using HTTP basic authentication. Would look similar like this screenshot:
https://cdn.wp.nginx.com/wp-content/uploads/2016/10/auth_required.png
Then the login prompt could tell everyone “username is same as password which is ‘whonix’ (without the quotes)”. Space for instructions and skinning is very limited in that prompt. A more pretty prompt might be developed later perhaps in two weeks from now.
Advantages: more anonymous since any member of public visitor could use the “login” (which is just a cheap, easy trick to get rid of 99% of bots which are non-targeted bots). Also more easy to type. No need to remember/type/copy/paste username / password.
Would that help?
Btw whonix.org is now redirected to www.whonix.org. No “plain”, non-subdomain.
Same for onion. www only. No non-subdomain onion.
(That was implemented to prevent duplicate crawling of both non-subdomain and www.)
(And all clearnet is always redirected to TLS.)
1 Like
Great thanks - yes, working fine now.
Good to know - yes, documented that in an edit.
Good to know and better for whonix.org long term server responsiveness, so that is definitely an improvement then.
Yes it would - please implement when you have some available time since it still effectively deals with the bots issue also.
1 Like
1 Like
<?php
if (file_exists('/whonix')) {
$wgSitename = "Whonix";
$wgFacebookAppID= '606207202785157';
$wgTwitterSiteHandle = '@Whonix';
$wgFavicon = "/w/images/a/a4/Whonix-home-favicon.ico";
$wgWikiSeoDefaultImage = "/w/images/2/2c/Whonix-facebook-post.jpg";
## https://github.com/wikimedia/mediawiki-extensions-WikiSEO/commit/3302424af82a2a2fb66591ad2de580e1dfd99135#commitcomment-64048390
$WikiSeoDefaultImage = "/w/images/2/2c/Whonix-facebook-post.jpg";
## 'svg' => "/w/images/1/19/Whonix-logo.svg",
$wgLogos = [
'1x' => "/w/images/thumb/f/f1/Logo_box.png/200px-Logo_box.png",
];
## avoid error:
## PHP Notice: Undefined index: SERVER_NAME in /etc/apache2/server.php on line 5
## when using:
## php /var/www/public/wiki/w/maintenance/dumpUploads.php --base "/"
if (!isset($_SERVER['SERVER_NAME'])) {
$_SERVER['SERVER_NAME'] = $_SERVER['SERVER_NAME'] ?? 'www.whonix.org';
}
if (preg_match("/dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/i", $_SERVER['SERVER_NAME'])) {
$wgServer = 'http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion';
$wgCanonicalServer = 'https://www.whonix.org';
$wgAllowExternalImagesFrom = array( 'http://127.0.0.1/', 'http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/' );
$wgRenderHashAppend = "www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion";
$wgCachePrefix = "www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion";
$wgFileCacheDirectory = "$IP/cache/www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion";
$wgLocalisationUpdateDirectory = "$IP/cache/www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion";
$wgCacheDirectory = "$IP/cache/www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion";
$MY_FQDN = "http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion";
} else {
$wgServer = 'https://www.whonix.org';
$wgCanonicalServer = 'https://www.whonix.org';
$wgAllowExternalImagesFrom = array( 'http://127.0.0.1/', 'https://www.whonix.org/' );
$wgRenderHashAppend = "www.whonix.org";
$wgCachePrefix = "www.whonix.org";
$wgFileCacheDirectory = "$IP/cache/www.whonix.org";
$wgLocalisationUpdateDirectory = "$IP/cache/www.whonix.org";
$wgCacheDirectory = "$IP/cache/www.whonix.org";
$MY_FQDN = "https://www.whonix.org";
}
$wgPasswordSender = "noreply@whonix.org";
## Needed even if default.
wfLoadSkin( 'Vector' );
}
if (file_exists('/kicksecure')) {
$wgSitename = "Kicksecure";
$wgFacebookAppID= '0';
$wgTwitterSiteHandle = '@Kicksecure';
## avoid error:
## PHP Notice: Undefined index: SERVER_NAME in /etc/apache2/server.php on line 5
## when using:
## php /var/www/public/wiki/w/maintenance/dumpUploads.php --base "/"
if (!isset($_SERVER['SERVER_NAME'])) {
$_SERVER['SERVER_NAME'] = $_SERVER['SERVER_NAME'] ?? 'www.kicksecure.com';
}
if (preg_match("/w5j6stm77zs6652pgsij4awcjeel3eco7kvipheu6mtr623eyyehj4yd.onion/i", $_SERVER['SERVER_NAME'])) {
$wgServer = 'http://w5j6stm77zs6652pgsij4awcjeel3eco7kvipheu6mtr623eyyehj4yd.onion';
$wgCanonicalServer = 'https://www.kicksecure.com';
$wgAllowExternalImagesFrom = array( 'http://127.0.0.1/', 'http://w5j6stm77zs6652pgsij4awcjeel3eco7kvipheu6mtr623eyyehj4yd.onion/' );
$wgRenderHashAppend = "www.w5j6stm77zs6652pgsij4awcjeel3eco7kvipheu6mtr623eyyehj4yd.onion";
$wgCachePrefix = "www.w5j6stm77zs6652pgsij4awcjeel3eco7kvipheu6mtr623eyyehj4yd.onion";
$wgFileCacheDirectory = "$IP/cache/www.w5j6stm77zs6652pgsij4awcjeel3eco7kvipheu6mtr623eyyehj4yd.onion";
$wgLocalisationUpdateDirectory = "$IP/cache/www.w5j6stm77zs6652pgsij4awcjeel3eco7kvipheu6mtr623eyyehj4yd.onion";
$wgCacheDirectory = "$IP/cache/www.w5j6stm77zs6652pgsij4awcjeel3eco7kvipheu6mtr623eyyehj4yd.onion";
$MY_FQDN = 'http://w5j6stm77zs6652pgsij4awcjeel3eco7kvipheu6mtr623eyyehj4yd.onion';
} else {
$wgServer = 'https://www.kicksecure.com';
$wgCanonicalServer = 'https://www.kicksecure.com';
$wgAllowExternalImagesFrom = array( 'http://127.0.0.1/', 'https://www.kicksecure.com/' );
$wgRenderHashAppend = "www.kicksecure.com";
$wgCachePrefix = "www.kicksecure.com";
$wgFileCacheDirectory = "$IP/cache/www.kicksecure.com";
$wgLocalisationUpdateDirectory = "$IP/cache/www.kicksecure.com";
$wgCacheDirectory = "$IP/cache/www.kicksecure.com";
$MY_FQDN = 'https://www.kicksecure.com';
}
## Needed even if default.
wfLoadSkin( 'Vector' );
$wgPasswordSender = "noreply@kicksecure.com";
}