In recent time, Tor has made the decision to use semi-persistent entry nodes which they call this feature “Entry Guards.” “Entry Nodes” are simply the first node you connect with to join the Tor Network, but an Entry Guard refers to the feature of pinning the entry nodes across sessions. The Tor Project asked the question “Is it safer to constantly change the first node you connect to or should that remain the same.” The conclusion was by choosing a static entry node, you statistically have a much lower risk of one your circuits being compromised in the case of resourceful state actors.
I’ll skip over the whole debate about why they did this. If you’d like to read more information about why they did this, you can read the article here. For the sake of discussion, let’s just accept this as truth and use this to highlight a situation that it creates:
1. Instance Leakage
In the case that you are running multiple instances of Tor because each instance uses a static guard, that means that passive adversaries are able to identify exactly the number of tor nodes you’re running on your network.
For example, you have a laptop, a relay, and some arm device that are all running Tor. In every instance, the tor binary is making a choice about its guard nodes to use. In every instance, it will (probably) make a different decision. This means that passive adversaries (ISP or the like) can take known guards, and watch your connections to them, and deduce how many tor instances are on your network.
One of the risks I’ve talked about in the past was the issues with the Harvard Bomb Threat where the campus network simply attributed the user because they built a list of all the people on campus using Tor. I think we should be sensitive to this attack because it’s very low resource even for local law enforcement. In the case that your ISP is logging your actions, and an event happened in your area, the first people they are going to start tracking are the people using tor. If they can see that you’re not only running Tor at a given point in time but 7 instances all the time, they might be knocking on your door first.
This issue alone is not as big as the bigger threat when you talk about traffic correlation attacks.
2. Traffic Correlation Weaknesses
In the past, Tor Project has recommended that you run relay alongside a client to increase your protection against traffic analysis. This recommendation is now wrong. The idea at the time was it would be hard to differentiate your traffic from relay traffic because you would be jumping around across circuits.
Because of the static guard nodes, it is much easier to differentiate between the traffic of each different instance. The relay that you’re running will connect to Guard A and the tor client that you’re running will connect to Guard B. From a traffic correlation perspective, it’s very easy to associate traffic of an individual tor instance to its traffic.
Here’s an attack example: You run a tor relay that uses Guard A. You have a tor client that uses guard B. Your adversary is able to watch traffic at your ISP and at the website you visit, www.nsa.gov, that you frequently visit with your client. If we did not use entry guards, the passive adversary would see lots of traffic going out over the tor network all the time including the traffic sent out by the client. It’s nearly impossible to differentiate between your client traffic and your relay.
But now that we have entry guards, a passive adversary watches the traffic of relay connecting to Guard A and sees that it’s a lot of consistent traffic. It then watches the traffic connecting to Guard B which is infrequent, the burst of traffic. It’s easy to tell that this is, in fact, a tor client. When you visit www.nsa.gov with your client, the passive adversary can easily correlate the time and size of the request with the one on the website.
What can we do?
My point is, for every network you use, you should be using the same guard nodes. If you are at a home network with 10 instances of tor, they should all be configured to use the same one.
Option 1: EntryNode in Torrc
If you want to specifically set what your guard nodes are, you can use the EntryNodes configuration option in your torrc file. Simple edit /etc/torrc with something like this:
EntryNodes FFFFINGERPRINTOFNODE1, FFFFFFFFINGERPRINTOFNODE2, FFFFFFFFFFFFINGERPRINTNODE3
This, unfortunately, has some costs. When you do it this way, you stop using tor’s intelligent guard selection algorithm that will choose guards for you based on a lot of properties of the Tor Network as a whole. You might want to change this on a regular basis or just have a long list of entry nodes that you use.
Option 2: Whonix
Whonix is a distro designed to be a tor gateway. It will manage a single instance of tor at the edge of your network and rather than have multiple instances of tor. Simply running a Whonix Gateway and routing your other clients connect into (ideally with the Whonix Client) will alleviate this issue. (You’ll have to choose if you trust the Whonix distro as a whole, though.)
Option 3: Tor Proxy Server
Don’t forget that tor runs as an SOCKS5 proxy. Although you’ve probably configured it to only listen on localhost, you can also configure it to be accessible on your internal network. When you setup all of the other instances of tor on your network, configure them to use the proxy server instead of 127.0.0.1:9050.
SOCKSPort 0.0.0.0:9050
I wouldn’t really do this for a variety of reasons. If you want to actually do this and put some protection on this service, see the TORRC details about SOSKPort flags so you don’t get yourself in trouble. Don’t forget, SOCKS is a cleartext protocol.
Option 4: Bridges
If you aren’t running a Relay, and you’re simply concerned about your standard traffic analysis attacks or counting tor instances you have on your network, you can configure your tor clients to use a bridge service. This will make it more difficult to detect that you’re using tor in the first place and skip around the issue completely.
185.100.84.187:57092 158A7DD6EDCA9041D7FA6ED7593E7BB43F82BD84 88.198.74.99:9001 3D6269A43BB28423D1127008A182EB07DBB39C00 199.231.94.203:443 0872E07DE33BEE2EB5D6A9941EBF30885A5D80D7
Option 5: Disable Entry Guards
The tor configuration file allows you to not use entry guards at all. If for some reason you’ve come to the conclusion that using a guard makes you less secure in your environment, dump them completely. This means that whenever a circuit is built, it will likely have a completely different entry node.
UseEntryGuard 0
Warnings
All of this being said, let me add the warning that making these configuration changes may cause more damage than when you started. It’s important to understand what the threats are and you can determine if this is important to your operation. If you are a standalone tor client user, there’s probably no reason for you to make customizations.
You should also note that if you somehow make your entry nodes static and you are on a mobile device, this could be a way of tracking you across sessions. If you take your laptop from your apartment to a coffee shop and there is somehow a way of collecting the traffic of both of them, they could correlate your entry guard usage across connections.
0 Comments