Kicksecure initates Tor connections by default to check for updates and download updates etc.
Is it dangerous to have Kicksecure active 24/7 even when not using it actively as state actors could potentially correlate connection patterns to deanonymize you?
Or is it even more dangerous to shutdown your Kicksecure device when not actively using it as they could correlate your Tor connections with your real life patterns, e.g. you shut down Kicksecure when leaving your physical location with your personal mobile device which is linked to your identity?
I am aware of this is an anoymity question and this is not a target of Kicksecure but related to Kicksecure.
Honestly I think the worst thing that could deanonimize you is the fact that I’m pretty darn sure the default handling or the tor state (Tails doesn’t persist the Tor state only saved bridges).
This means that you connect to your home WiFi SSID and then connect to a public WiFi network. You will have the same entry guards on both networks or really all saved network connections actually.
If I’m wrong about this someone correct my reply cause last I checked tor daemon config with be used for all saved connection.
What I think Kicksecure and (would be good for Whonix host) is to set different guards for each saved connection. I’m not sure how you implement this but here are some approaches worth looking at.
Two approachs would require some scripting:
1st Approach: One torrc template + different DataDirectory per SSID
The DataDirectory directive tells Tor to keep its cached-descriptors, state, and therefore its guard list in that directory. The first time it runs it will build a fresh set of guards.
- Create a torrc template (~/tor-templates/torrc.template). Leave out the two lines that change per SSID – DataDirectory and UseEntryGuards – inject them later.
- Write a small wrapper script that Network Manager will call from /etc/NetworkManager/dispatcher.d. It receives the SSID as $1:
Approach 2 – A completely separate torrc file per SSID
Create a directory ~/nm-tor/ and drop as many torrc files as you like. Essentially a process that listens for saved network-manager names and saves the name for each torrc file. This makes the dispatching tor simpler for scripting.
A completely new DataDirectory means Tor will bootstrap from an empty cache and discover its own, isolated set of entry guards:
Same torrc file, different directory → different guards
Different torrc files pointing at different directories → also different guards
If so I don’t think so but idk why you would unless you are using Kicksecure as a server of sorts?
Again you mean kill the Tor daemon connection?
The only thing a ISP or someone monitoring your network could see is when you bootstraped (connected to Tor) and when you disconnected from Tor.
In relation to your mobile device I would say as long as you are using mac address spoofing and not using a obvious or unique hostname (eg. Your first name). Then I would say you are fine if you are connecting to the same network you are using Kicksecure on. Realistically if you phone is turned on when you leave they can track your location. They can also see if you phone is turned off. If whatever you are doing requires a high threat model, I would leave your phone turned on and at home or turn it off and put it faraday bag. Phones are basically the cop in your pocket.
@Patrick What is recommended to be done against guard fingerprinting when using Kicksecure and changing locations?
If using Whonix you could just use a new Whonix-Gateway but how should we handle this with the underlying Kicksecure OS which also uses Tor by default immediately when starting?
Yes that is what I mean. As far as I know Kicksecure connects immediately to Tor and keeps the connection. For example you want to access Tor multiple times a day and do not want to shut down and restart Kicksecure every 1-2 hours. Is it a risk to keep it running and should you always shut down or disable the network connection as soon as it is not in active use?
Yes. Does the ISP see the connection / bootstrapped and disconnection process two times, i.e. first time by Kicksecure and second time by Whonix-Gateway (if used)?
Did I get it right that you are talking about using mac address spoofing on the Kicksecure device? Thanks, it makes sense to leave the phone at home.
Hmmm well, if you don’t need the Tor service to run for user you may be able to restrict it for user and only have it enabled for sysmaint for updates/upgrades. Take in mind the sdwdate relies on Tor for time sync also which is imperative for certain things to work correctly like certificates and 2fa applications etc.
If this is the case for you, I wanted to suggest systemctl --user disable tor.service && systemctl --user mask tor.service if you don’t want the tor daemon running for user user but the tor.service is system wide not a user level service so tha wont work I’m sure? hmmm…
I’m not sure if its a simple thing of removing user from the debian-tor group so you would be best to go the polkit route @adrelanos@arraybolt3 what do you think?
This use case could documented in the wiki but I personally like the Tor service to load for user since I like to route certain applications through the socks port 9050 like Electrum and Feather wallet.
Please don’t remove or change how Tor is implemented please. I personally think the Tor service should not change as it’s one of the main reasons people may choose to use Kicksecure since its shipped with it making it great for running hidden services on a server.
Tor only runs as a system-level service to my awareness, there is no file matching the pattern /usr/lib/systemd/user/*tor* that is actually Tor-related.
The only users in the debian-tor group are canary, systemcheck, and sdwdate. Removing users from that group will probably break things and leave Tor enabled. I’m not quite sure that the “polkit route” is, but it’s worth bearing in mind that things that usually would pop up polkit prompts probably will not work except in sysmaint mode due to SUID stripping. (This isn’t that much of a problem usually since you’re not supposed to run privileged things in a user session.)
Kicksecure isn’t really designed to work without Tor enabled and running. Not only will disabling it break apt and sdwdate, there is code in Kicksecure specifically designed to start Tor if it isn’t running so that things like apt and sdwdate will function. If you have to disable Tor for some reason, then you would need to mask it system-wide, which will break it for both user and sysmaint sessions, require that you un-torify apt sources, leave you without clock synchronization, disable the automatic warrant canary checks, and will potentially make you more vulnerable to some sophisticated attacks. If you’re in an area where Tor is censored, maybe that’s a risk you’re willing to take, but in that instance, masking Tor system-wide is the right thing to do.
Should be the same steps as for connecting Tor to a bridge in general. apt (as configured by Kicksecure) uses Tor as a proxy to download updates through, so if Tor connects via a bridge, the system should be able to get updates through the bridge as well.