Implications of multiple Tor instances and some custom Torrc options?

I am running two Tor instances per host (or in one case three (because it’s mainly a relay and I think I have seen it warn about not running relay and personal traffic or hidden service on the same instance) and I wonder if it’s secure or if there is something that I am not taking into account.

  • One hop onion service for having faster SSH access in case other means of access fail (most of these are behind CGN and dynamic IPs).
  • Client for systemwide Tor, because one hop onions require SocksPort 0.
  • In one case the main instance is a relay (otherwise it’s the one hop onion).

So far I have reached conclusion that the only risk of this setup is accidentally letting apps like Ricochet or Zeronet create hidden services on the NonAnonymous/SingleHop instance (I have currently unanswered question on whether this is possible with Zeronet at their documentation tracker), is there something I am not thinking about?

To counter this, I have set:

ControlPort 0
ControlSocket 0

in the main torrc and

CookieAuthentication 1
CookieAuthFileGroupReadable 1
CookieAuthFile /run/tor/control.authcookie
ControlPort 9051
ControlSocket /run/tor/control GroupWritable RelaxDirModeCheck
ControlSocketsGroupWritable 1

to torrc-client, I have picked them from Debian’s /usr/share/tor/tor-service-defaults-torrc which results to nyx and Zeronet using the Tor-client instead of the onehop Tor. I think that at this point everything using systemwide Tor should behave as if I never touched /etc/torrc, does this seem correct?

And then there is the torrc-client which is responsible of the SocksPort and there I have three options I am not sure about:

SocksPort 9050 IsolateDestAddr PreferIPv6
  • 9050 is the default port which everything using system-wide Tor (mainly apt-transport-tor for me) expects and it’s a default, so it’s fine, but
  • IsolateDestAddr is something I see adviced on the chat, but I am wondering does it make me more unique, Tails design doc on stream isolation thinks that it may be the case for web browsing, which I am naturally not doing as Tor Browser has it’s own Tor instance which torrc I am not going to touch, but for other traffic there is a question:
    • These settings probably put more load on the network. On the other hand, the Tor people probably are happy with people using it given they have added the option in the first place. We will anyway ask them to review our proposed configuration with network load in mind before we ship it to the masses.

    • and this option is available as a checkbox in Orbot settings (unless there are multiple stream isolations).
  • PreferIPv6, it’s 2018 and CGNs are coming everywhere, of course I want to prefer IPv6! But as Tor defaults to not preferring IPv6 even if the exit node happens to support it, am I again making myself more unique? Why is it not default? Is it that Tor doesn’t behave with IPv6 that well yet, or that Tor DNSEL is IPv4-only and by using IPv6 exits there may be less captchas or blocks, is that supposedly an open secret?
  • I get the feeling that the correct answer would be SocksPort 9050 OnionTrafficOnly with which at least apt-transport-tor would be happy and possible the other apps I mentioned. Would that be a good idea, it seems like one as I could just open another port for the apps accessing clearnet?
    • EDIT: Zeronet doesn’t seem to be happy.
      • Tor-client[XXXX]: Refusing to connect to non-hidden-service hostname or IP address [scrubbed] because Port has OnionTrafficOnly set (or NoDNSRequest, NoIPv4Traffic, and NoIPv6Traffic).

ClientUseIPv6 1

Some of my previous questions apply to this, why is Tor not allowed to use IPv6 for connections to guards by default? Am I compromising my anonymity to more than the guard node? I am behind CGN on IPv4, so I think it’s theoretically possible for there to be multiple Tor users between the same public IPv4 address and in that scenario I may be less anonymous to the guard. I think yesterday I read from GitHub that at least Onionbrowser for iOS users have this option enabled, so my nodes aren’t the only ones accessing guards though IPv6.

Another important question is probably if any of this matters as I am mainly either providing cover traffic or accessing specific onions in the background instead of doing anything sensitive, but I guess I am just curious.

More complete copies of my torrc are here, but I don’t tink there is anything else weird than what I am asking about in this post and torrc-client.service & co are here, but their main point is just /usr/bin/tor -f /path/to/config .

1 Like

I forgot another question, what is “guard context “default””?

Starting with guard context "default"

After this I have checked /etc/torrc on Tails and seen that it has IsolateDestAddr and IsolateDestPort enabled, so I think it’s also fine.

The other change is CookieAuthFile 0 in the main torrc, because otherwise the two Tor instances seem to confuse each other.

tor has 3 types of nodes, guard context is the mode it’s in.
IRC default = guard/middle.
…guard context “bridge” is the other option.
and exit not sure what the term is.

I just wonder how I don’t see that messages from Tor that has been started by upstream systemd unit.