First node always the same! Is that how it's supposed to work?

Question

I'm using Tor-browser-bundle with Vidalia. Yesterday, just out of curiosity, I clicked on "view the network." In the "connection" box, I see my circuits. About 5, 6 circuits each with 3 different nodes. Then I realised something : only the 2 last nodes are different, the first is always the same IP. So I click on "new identity" and guess what ? Same first node again. Exit node have changed, very well, but the first relay is the same.

Is that how it's supposed to work?

Answer 1

Tor is supposed to work in this way. Former versions of Tor built a complete new circuit every time. However some researcher found out that a so-called service location attack is possible. So the Tor Project changed the design in a way that defends this kind of attack. The defense is that the first relay in a circuit stays the same for some period of time. This node is now called guard node.

Usually Tor keeps using the same guard node for several weeks. Tor uses a state file (within your Tor installation) to keep track of guard nodes. You'll find several lines like:

EntryGuard AloneWithOurRecords 783C36CF2F61A1B3C4238499D92C619A9CDDEA3B DirCache

in this file. Those lines determine the guards you'll use.

Answer 2

This is the normal behaviour for entry guards.

The Tor FAQ explains why we'd want to do this:

... But profiling is, for most users, as bad as being traced all the time: they want to do something often without an attacker noticing, and the attacker noticing once is as bad as the attacker noticing more often. Thus, choosing many random entries and exits gives the user no chance of escaping profiling by this kind of attacker.

To simplify: the more often you change your guard node, the more chance there is of connecting to one owned by the Bad Guys.

The length of time you use the same guard for is called the rotation period. More details about this can be found in Changing of the Guards and One Fast Guard for Life.

Answer 3

This is your "Entry Guard", it acts as a protection mechanism. It is kept long term because it makes it harder for adversaries to deanonymize Tor users, since most of the attacks on onion routing require control of the entry and exit points to the network.

Imagine that some entry points are, hypothetically, naughty. Every time you pick a new entry point you are rolling a set of die and if the numbers come up wrong you might be subject to a naughty guard trying to perform a deanonymization attack, linking your activity on Tor to your identity. As such, the fewer times that you roll the die the less likely you will be to pick a naughty guard.

For more information on why you want to keep this guard for a longer time period, read this blog post: https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-parameters

Answer 4

Looks like the single guard node proposal is implemented now: "...in its first startup, Tor picks one guard and stores its identity persistently to disk. Tor uses that guard node as the first hop of its circuits from thereafter."

More info: https://trac.torproject.org/projects/tor/ticket/11480

Answer 5

This article shows, that clients are rotating their guard nodes every 4-8 weeks.

https://blog.torproject.org/blog/lifecycle-of-a-new-relay

It isn't optimal to allow this temporary dip in traffic (since we're not taking advantage of resources that you're trying to contribute), but it's a short period of time overall: clients rotate their guards nodes every 4-8 weeks, so pretty soon some of them will rotate onto your relay.

So your client is looking for a guard flagged relay (entry relay) and after a certain amount of time (4-8 weeks) it is rotating to another entry relay.

I think they didn't implemented the proposal yet because the milestone is set to 0.2.6.x-final in trac.

Answer 6

It's about pre-seeding, so what I'm recommending to people :

• At first, use default setup and well-known working connection and run Tor with directory mirror enabled and seed it
• Later you can do if you want : UseEntryGuards 0 and use any of Tor nodes, to make paths more random
• Take a spin for EntryNodes + ExitNodes + StrictNodes - play with it!

Answer 7

The first of the three relays in the circuit is called the entry guard.

The entry guard will stay the same for a period of time (several months - this is called the rotation period), even when you create a new circuit. This is expected and by design.

See this previous question: In Tor Browser, I connect to the exact same entry node all the time, unable to change it (notice: that question has now been merged with the current question)

Answer 8

Yes i see it too. I think it's because when you choose a guard node (the first node out of the three) you stick to the same one for 4-8 weeks as describe here "clients rotate their guards nodes every 4-8 weeks". (https://blog.torproject.org/blog/lifecycle-of-a-new-relay)

Answer 9

Fred is right. From a probability perspective, if one in ten relays are compromised, you always have a one in ten chance of getting the compromised relay. Therefore, there is no advantage to forcing the use of one relay. However, if an entity (with the help of your internet provider) were to direct your Tor request to a compromised relay, you would have no way to randomize relay choice to minimize your chance of getting it. In this case, you have a 100% chance of using a compromised relay.

I'd like to see the mathematical analysis behind this policy because it seems to make hijacking much more possible.

Answer 10

So after reading this answer by Jens, I looked for and found this "state" file in [...]\TorBrowser\Data\Tor , deleted it and finally got a realy new circuit because the TBB created a new file after restart.

This was really crucial to me, because the friggin Ukrainian "guard note" it used before drove me nuts, because it was so unbeliviably slow it rendered tor unusable to me. And that cannot be the goal of a "security improvement", since it would eventually drive me to use a normal browser if it had continued for another couple of weeks :o .

So @developers, please don't make this "fix" impossible.

Answer 11

In an e-mail, Tor project leader Roger Dingledine said the requirements of the attack greatly limited its effectiveness in real-world settings. First, he said, the adversary must control one of the entry guards a hidden service is using. Such entry guards in theory are assigned randomly, so attackers would have to operate a large number of Tor nodes to have a reasonable expectation of seeing traffic of a given hidden service. Additionally, he cited research from last year arguing that researchers routinely exaggerate the risk of website fingerprinting on anonymity.

A response to another research that claimed they could de-anonymise TOR. Clearly the bit about entry guards being assigned randomly is not true.