Feature #5462

Persistence preset: Tor state

Added by Tails almost 2 years ago. Updated 23 days ago.

Status:ConfirmedStart date:
Priority:NormalDue date:
Assignee:-% Done:


Target version:Tails_3.0
QA Check: Blueprint:
Feature Branch: Easy:No
Type of work:Code Affected tool:


Big picture

There are a few good reasons for making Tor's data dir persistent:

  1. Faster and less wasteful (in terms of bandwidth) bootstrap.
  2. Stronger resistance to certain attacks against anonymity via persistent Entry Guards.
  3. Using Entry Guards makes it harder to detect that you're using Tails.

Making /var/lib/tor persistent is enough for this. We should probably make a preset for it. Should it be enabled by default?


Persistent entry guards vs. mobile users

using persistent Entry Guards may be problem for mobile users (https://lists.torproject.org/pipermail/tor-talk/2012-October/025975.html).

Potential solutions:

Custom scripts relying on non-persistence

Some of our scripts depend on that certain files in /var/lib/tor are not persistent, which has to be resolved before adding the preset:

  • Our time syncing script uses the existence of cached-descriptors as a test for wheter Tor is working, and a similar assumption is made for the *-consensus files.
  • The Unsafe Browser uses cached-descriptors in the same way as the time syncing script.

At least "cached-descriptors existence checking" can be replaced with checking "GETINFO status/circuit-established" via the ControlPort. For tordate's *-consensus magic "GETINFO status/enough-dir-info" seems interesting, but isn't a replacement.

Shell function which is useful for the above:

tor_control_getinfo() {
  HEXCOOKIE=$(xxd -c 32 -g 0 $COOKIE | cut -d' ' -f2)
  nc 9051 | grep "^250-${1}=" | sed "s@^250-${1}=@@" 

Related issues

Related to Tails - Feature #5461: Persistence preset: Tor configuration Confirmed


#1 Updated by intrigeri over 1 year ago

  • Category set to Persistence
  • Easy set to No

#2 Updated by Anonymous about 1 year ago

(removed spam)

#3 Updated by Anonymous about 1 year ago

(removed spam)

#4 Updated by intrigeri about 1 year ago

  • Description updated (diff)

#5 Updated by Anonymous about 1 year ago

(removed spam)

#6 Updated by Anonymous about 1 year ago

(removed spam)

#7 Updated by Anonymous about 1 year ago

(removed spam)

#8 Updated by BitingBird 10 months ago

  • Subject changed from persistence preset - tor to Persistence preset - tor

#9 Updated by intrigeri 9 months ago

  • Subject changed from Persistence preset - tor to Persistence preset - Tor state

#10 Updated by intrigeri 9 months ago

  • Description updated (diff)

#11 Updated by sajolida 3 months ago

#12 Updated by BitingBird about 1 month ago

  • Subject changed from Persistence preset - Tor state to Persistence preset: Tor state

#13 Updated by intrigeri about 1 month ago

#14 Updated by anonym 23 days ago

I had a look at the tools solving the "Persistent entry guards vs. mobile users" problem:

Subgraph's torshiftchange

It detects network based solely on NetworkManager's connection uuid. While that approach will work fine do wireless networks (since they always generate a new connection => new uuid), I don't see how we can get around treating all wired networks as the same one and hence getting the same entry guards for all wired connections.

Hmm. And actually, I guess it would be a problem for eduraom network and similar "global" networks where one normally would configure one NM connection without a BSSID but only an SSID. OTOH, with eduroam specifically one uses a certificate that's unique per user, but I've seen other (generally unencrypted) networks of this type, e.g. for chains of some company that provide free wifi. Perhaps they sometimes deliberately use the same BSSID (i.e. spoof the AP's MAC address to all be the same) in addition to the same SSID?


It identifies network based on BSSID, so for a wireless network it'd be the AP's MAC address. For a wired network there's no BSSID concept, so I'm not sure what it means in that case. That seems to be specific for wicd; tordyguards is written as a wicd pre-connect script, and those are supplied with these parameters:

$1 - the connection type (wireless/wired).
$2 - the ESSID (network name).
$3 - the BSSID (gateway MAC).

where the third argument (the BSSID) is the only one used. Unfortunately, NetworkManager doesn't provide the BSSID, so add support for it one would have to take a detour with nm-tool or nmcli or something to get the BSSID. Also, something I don't like about it is that it's designed to also start and stop the Tor service, instead of just fixing /var/lib/tor/state.

What to do?

Any way, the good idea in tordyguards is to identify the network based on something that is a persistent property of the network itself, like its BSSID. Like I said, I don't know what the BSSID concept means for wired networks, but the take home lesson is that we should do something based on MAC addresses, IMHO. I quickly hacked together a PoC that uses the gateway's MAC address (if any, otherwise a new Tor state file is used => random entry guards). See the branch feature/5462-PoC-for-per-network-entry-guards.

Still, to not reinvent the wheel and go completely NIH, perhaps we should ask the Subgraph people if they want to consider switching torshiftchange from identifying networks based on the NM connection uuid to looking at the gateway MAC address. I suppose we should also carefully analyze if there's any problem with that (for instance, do "global" network spoof the gateway MAC addresses to be the same everywhere? I doubt it, but it's worth considering). Also, we need to come up with what to do when multiple NICs are connected at the same time (how that works in Tails is a bit messy at the moment, and my PoC messes it up a bit more I think).

Also available in: Atom PDF