[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Configuring Whonix connection to Tor through a *single* trusted entry guard

Hello,

In the aftermath of the relay early attack and in order to significantly reduce one’s exposure to traffic confirmation attacks in general, one can restrict entry access to Tor through a single trusted entry guard.

Assume I have a Tor relay “SweetRelay” set up somewhere that has earned the guard flag, that I trust it, and that I want to use it as my sole entry guard.

Normally, I would just go to my client Tor config file (/etc/tor/torrc) and add:
EntryNodes SweetRelay
NumEntryGuards 1

MY QUESTION IS: Can I make this same modification to /etc/tor/torrc on Whonix gateway and achieve the same result (i.e. Whonix only connecs through my trusted entry guard)?

Thanks in advance for input.

I haven’t tested this config. Check using arm (https://www.whonix.org/wiki/Arm) if it worked.

As per,

Nevertheless, I wouldn’t recommend these changes on your own. I’d wait until this becomes the official setting to share the same anonymity set as everyone else. But that is up to you.

Patrick, thanks for your very prompt and informative response.

Theoretically, assuming this setup “works”, wouldn’t permanently routing through a trusted guard prevent my torrified Whonix traffic from getting correlated (unless up against a global adversary)?

It seems to me that even with persistent guards, that if Whonix picks one or more bad ones and sticks with them, I’m hosed.

Conversely, if I am constantly mobile and spoofing my MAC address from public wifi hotspots, would it not be to my advantage to choose a new set of guards from each new connection location (i.e. delete my tor state file as per recommendation in the advanced security guide)? In this scenario, my MAC address is not geographically trackable nor can I be profiled from my repetitive use of same set of guards as a Unique Identifier.

Sorry…I realize these are two completely different questions. Any further insight is appreciated

If I understand this right, just having one trustworthy entry guard doesn’t defeat all attacks. A compromised entry guard is able to try a traffic confirmation attack, so the consideration to only use 1 entry guard and hope it isn’t compromised, may be indeed a good idea. But that only covers entry guard level attacks. The problem is, ISPs are also “permanent entry guards” and malicious/compromised ISP’s might still be able to try such attacks.

Tor picks them and Whonix doesn’t interfere. So you might be better off getting assurance from the official Tor support channels.

Using just 1 guard node also is a pretty non-standard thing to do what probably not many users are doing (I guess), so it would be also kinda a unique identifier.

This is a good question. We don’t have documentation for that yet. Best you can find is this:

You might be interested as well (because using a single bridge might be less non-standard then a single entry guard at this time):

Thank you for all of the insight and resources. Doing my research. Have a great weekend.

Another question.

I was attempting to change my entry guards by deleting /var/lib/tor/state as per the advice for using whonix (in conjunction with changing MAC address) on a open public network (see https://www.whonix.org/wiki/Pre_Install_Advice#MAC_Address).

After I did so, I re-started TOR, cat /var/lib/tor/state and the same set of guards were selected. Deleted the file again, rebooted, and still got same guard selection set.

Is there something I am doing in correctly in order to properly cause TOR to select new entry guards for Whonix gateway?

I just now added this information to the wiki so everyone can read it:

(Also isn’t Whonix specific.)

This is most likely also possible in other ways, by using Tor Control Protocol or maybe even other methods.

You’ll find out by reading
https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=control-spec.txt
and/or
this would also be a good general non-Whonix specific Tor question for


and/o
tor-talk mailing list (https://lists.torproject.org/pipermail/tor-talk/).

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]