After stopping Tor, /var/lib/tor had to be unmounted. When moving new Tor folder back into /var/lib the new folder did not need to be mounted for Tor to start. Should it be mounted anyways?
It’s mounted by bind-dirs. So when manually unmount it would have to be
manually remount the same way bind-dirs does.
Probably better to use:
rm -r /var/lib/tor/*
To avoid any mount / unmount.
But then the user needs to be careful not to use any extra space before
the asterix /var/lib/tor/ *.
Note: Whonix maintains compatability with both v2 and v3 onion services so users can access web resources while staying in the Tor network. However, users are encouraged to use v3 (next generation onion services) when visiting whonix.org. This will allow users to benifit from the many improvements over the v2 legacy system.
homepage v2 onion v3 onion
wiki v3 onion
forums v3 onion
downloads v3 onion
phabricator v3 onion
debian repository v3 onion
If I understood correctly, you wanted only 1 mention of v2 onions on whonix.org i.e. forcing_onion chapter?
Superscript for references. Wordpress allegedly allows superscript with <sup>1</sup> etc. But when you use this, it just appears in plain text. Unlike in this forum where it works e.g. 1
Tried the markdown to HTML converter, didn’t work for me. Wordpress… harder to configure than Whonix
Note: Whonix maintains compatability with both v2 and v3 onion services so users can access web resources while staying in the Tor network. However, users are encouraged to use v3 (next generation onion services) when visiting whonix.org. This will allow users to benifit from the many improvements over the v2 legacy system.
homepage v2 onion v3 onion
wiki v3 onion
forums v3 onion
downloads v3 onion
phabricator v3 onion
debian repository v3 onion
If I understood correctly, you wanted only 1 mention of v2 onions on whonix.org i.e. forcing_onion chapter?
When step 3 was reverted back to previous command I failed to remove the asterisk (*).
With the change, Tor file can now be removed. Since this directory is mounted by bind-dirs, it will always complain resource busy?
user@host:~$ sudo rm -r /var/lib/tor rm: cannot remove '/var/lib/tor': Device or resource busy user@host:~$ sudo ls /var/lib/tor (no output)
Also, 2 out of 10 times moving Tor state file from sys-whonix-13 to sys-whonix-14, Tor (sys-whonix-14) would not start due to missing DisableNetwork 0 in torrc.
Its likely I made a mistake but couldn’t find anything in command history.
BTW, fully tested intructions and everything works as it should with the new edit.
None is very elegant. Isn’t there a better linux command?
user@host:~$ sudo ls /var/lib/tor (no output)
Also, 2 out of 10 times moving Tor state file from sys-whonix-13 to sys-whonix-14, Tor (sys-whonix-14) would not start due to missing DisableNetwork 0 in torrc.
DisableNetwork 0 should have Tor start but not connect. Is that what is
happening?
Its likely I made a mistake but couldn’t find anything in command history.
Maybe also a bind-dirs issue?
Could you please also mention torrc migration? Mostly interesting for
users who changed torrc settings.
@0brand - You’ll lick your lips with this. The key to editing longevity is balancing the boring shit (eg sys-whonix Tor state), with the fun.
Now, everybody loves unbreakable encryption. “It doesn’t exist” they say? Well, we know that is not true with One Time Pads (OTPs) used properly providing perfect encryption.
Now I’m talking about the physical creation of OTPs, not the electronic program fails which can of course be backdoored by adversaries 6 ways since Sunday.
Anyway, there is no wiki page for that, so I just created an empty one. This is a good guide below that summarises the technique nicely. Of course, multiple dice always comes in handy for generating true randomness where required; no backdoored “RNGs” for us. People don’t need fancy 10 sided dice and all that crap. It can be accomplished properly with good technique with 6 sided dice, to adjust for statistical issues that would otherwise not create true randomness.
Why you say?
If this is wrapped up with the GPG email encryption guide when finished, our most paranoid friends could wrap up a OTP message, inside of a GPG-encrypted email, thrown 100% through the Tor network, using a truly anonymous email account, via an .onion server. And with icing on the cake, we can eventually add the “Jason Bourne” GPG key creation guide from the terminal, so users have the hottest key generation and strongest algorithms going around.
Gives me a stiffie thinking about it. ha ha. Anyway, I suggest you start with One Time Pads, instead of that proxy crap, since that is piecemeal, and this is fun.
I didn’t have time to thoroughly read through the paper but this does look really cool! Plus its easier (for me at least) if the chapter can be started from scratch.
Another benefit to having individual wiki pages is users can more easily find what they are looking for without having to role the dice and sift through an entire page.
“Jason Bourne” GPG key creation will definitely look good along side one time pad. I think this page will perk interest with Quantum computers just around the corner? Possibly here already?
Once i get “sys-whonix Tor state” completed I have a few other small thing to complete and then I can start this
Also
VirtualBox troubleshooting wiki enhancement
Low RAM issues (VMs freezing)
TODO
May have to quit my job so I can work on wiki full time!
I’m writing this post in reverse order. You’ll see why
I think it is bind-dirs. I’m not sure exactly whats happening but I was able to reproduce the behavior 1 more time.
Just to recap, this happens intermittently when the following command is used to remove the Tor folder.
sudo rm -r /var/lib/tor
When all step are complete, expected behavior.
sudo systemctl start tor@default
user@host:~$ whonixcheck
[INFO] [whonixcheck] sys-whonix-14 | Whonix-Gateway | whonix-gw TemplateBased ProxyVM | Fri Apr 13 21:25:44 UTC 2018
[INFO] [whonixcheck] Connected to Tor.
[INFO] [whonixcheck] Whonix APT Repository: Enabled.
When the Whonix team releases STRETCH updates,
they will be AUTOMATICALLY installed (when you run apt-get dist-upgrade)
along with updated packages from the Debian team. Please
read https://www.whonix.org/wiki/Trust to understand the risk.
If you want to change this, use:
sudo whonix_repository
[INFO] [whonixcheck] Debian Package Update Check: Checking for software updates via apt-get... ( Documentation: https://www.whonix.org/wiki/Update )
^Cwhonixcheck: signal SIGINT received. Cleaning up... Exiting...
[INFO] [whonixcheck] whonixcheck aborted! (SIGNAL_TYPE: SIGINT
Actual behavior
user@host:~$ whonixcheck
[INFO] [whonixcheck] sys-whonix-14 | Whonix-Gateway | whonix-gw TemplateBased ProxyVM | Fri Apr 13 21:26:47 UTC 2018
[WARNING] [whonixcheck] Tor Check Result:
Tor is disabled. Therefore you most likely can not connect to the internet.
(Debugging information: Could not find DisableNetwork 0 in Tor config.)
Please close this window and enable Tor using Whonix Setup!
dom0 -> Start Menu -> ServiceVM: sys-whonix-14 -> Whonix Setup
or in Terminal: sudo whonixsetup
or manually (If you know about the public Tor network!) and open /usr/local/etc/torrc.d/50_user.conf with root rights
(dom0 -> Start Menu -> ServiceVM: sys-whonix-14 -> Torrc) and set:
DisableNetwork 0
Tor is functioning though
user@host:~$ sudo systemctl status tor@default
● tor@default.service - Anonymizing overlay network for TCP
Loaded: loaded (/lib/systemd/system/tor@default.service; static; vendor preset: enable
Drop-In: /lib/systemd/system/tor@default.service.d
└─30_qubes.conf, 40_obfs4proxy-workaround.conf, 40_qubes.conf, 50_controlsocke
Active: active (running) since Fri 2018-04-13 21:27:03 UTC; 29s ago
Process: 2007 ExecReload=/bin/kill -HUP ${MAINPID} (code=exited, status=0/SUCCESS)
Process: 5278 ExecStartPost=/bin/kill -HUP ${MAINPID} (code=exited, status=0/SUCCESS)
Process: 5273 ExecStartPre=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-def
Process: 5271 ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d
Main PID: 5276 (tor)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/system-tor.slice/tor@default.service
└─5276 /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc
Apr 13 21:27:03 host Tor[5276]: You configured a non-loopback address '10.137.0.43:9184'
Apr 13 21:27:03 host Tor[5276]: You configured a non-loopback address '10.137.0.43:9185'
Apr 13 21:27:03 host Tor[5276]: You configured a non-loopback address '10.137.0.43:9186'
Apr 13 21:27:03 host Tor[5276]: You configured a non-loopback address '10.137.0.43:9187'
Apr 13 21:27:03 host Tor[5276]: You configured a non-loopback address '10.137.0.43:9188'
Apr 13 21:27:03 host Tor[5276]: You configured a non-loopback address '10.137.0.43:9189'
Apr 13 21:27:03 host Tor[5276]: You configured a non-loopback address '10.137.0.43:5300'
Apr 13 21:27:03 host Tor[5276]: You configured a non-loopback address '10.137.0.43:9040'
Apr 13 21:27:03 host Tor[5276]: Opening Control listener on /var/run/tor/control
Apr 13 21:27:03 host Tor[5276]: DisableNetwork is set. Tor will not make or accept non-co
After running sudo whonixsetup error still persists with whonixcheck.
Manually adding DisableNetwork 0 to /usr/local/etc/torrc.d/50_user.conf fixed problem
Thought you might be interested?
For the Tor wiki, this command was added to remove Tor folder
Option a)
sudo su sudo rm /var/lib/tor/*
Now the reason for this post being backwards
I saw a possible problem. Users may see this command and wonder why not just use?
sudo rm -r /var/lib/tor
Possible someone like myself would actually try using this? This may cause problems with broken bind-dirs and possible what happened with above whonixcheck? So I added a warning in the footnote about consequences of not following instructions as written.
Should this be taken out of footnote and placed at top of instructions?
Users are strongly encouraged to follow the instructions as they are written. This is because deviation from the listed commands could have unforeseen consequences. For example, if users where to use a alternate command to remove the Tor state folder. The outcome may be broken file persistence across reboots. This is owing to the fact that Qubes-Whonix uses bind-dirs file persistence for the Tor folder and other select directories. This in turn, at the very least would require users to umount and mount the Tor folder in the same way as bind-dirs does. This would likely be very timely and complicated.
Also added note on migration of torrc
Users with custom Tor configurations options, which are also referred to as custom torrc options, are required to migrate those settings separately. This is on account of the Tor state folder, which is located in /var/lib, does not contain the custom torrc settings that are located in /etc/tor/torrc for Whonix 13, and /usr/local/etc/torrc.d/50_user.conf for Whonix 14 and later releases.
If you like, please generalize that chapter (or make sub chapters if
that looks good) for a full migration (Tor state folder and torrc).
0brand:
Possible someone like myself would actually try using this?
Yes, quite likely.
This may cause problems with broken bind-dirs and possible what happened with above whonixcheck? So I added a warning in the footnote about consequences of not following instructions as written.
Should this be taken out of footnote and placed at top of instructions?
Yes, very much so. A short warning box with a footnote to explain why.
1. Add gpg fingerprint check steps to OnionShare and elsewhere it is a forgotten step in Whonix, since we shouldn’t blindly trust the long key ID by itself.
SHA512 hashing algorithm & personal cipher preferences to the strongest i.e. setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
Stronger digest when receiving signed messages privately (via setpref preferences).
Expiration date less than two years.
Generate a revocation certificate.
Separate subkey for signing.
Primary key entirely offline (secret_key).
Test quality of key pair with hopenpgp-tools.
Check primary keys are using RSA.
Check bit-length of primary key.
Self-signatures issues e.g. not use SHA1 etc.
ASCII-armored version of public key (?)
Transforming the master keypair into the laptop keypair (removing original signing subkey from the master keypair in our keyring)?
Anything else to consider for a strong GPG key pair?
TODO Mention configuring Split GPG in Email section →
4096 bit for sure. Some of these things are already in the wiki. But Air Gapped OpenPGP Key - Kicksecure is quite lengthy and not everyone’s cup of tea.