5

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?

5
  • I've removed part two of your question as it doesn't really relate to the rest of the question; feel free to ask it as a separate question. Thanks!
    – Sam Whited
    Nov 15 '14 at 18:52
  • please post your torrc and tor log/output and for how long it's locked? I'll be able to help you further if I will have more info
    – Alexey Vesnin
    Feb 9 '16 at 15:14
  • BTW, whenever I log on, the first entry node is in Netherlands and is always the same 84.92.251.204.
    – Bob
    May 5 '16 at 7:13
  • 1
    This is expected. Entry guards stay the same for a period of several months, which is by design. The other nodes in your circuit will change though. May 5 '16 at 7:31
  • 1
    If you desperately want to change your entry guard - which is actually less secure than leaving it the same - have a read of this thread: tor.stackexchange.com/questions/4880/… May 5 '16 at 9:05

11 Answers 11

16

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.

4

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.

2
  • Thanks for your answer. Just one question about this part of your answer: "To simplify: the more often you change your guard node, the more chance there is of connecting to one owned by the Bad Guys." If TOR always connects to the same IP how do I know this isn't a "bad guy" anyway. Is there any way of validating the "good guy" status of what you call an entry guar?
    – negrita
    May 16 '16 at 7:51
  • To simplify: the more often you change your guard node, the more chance there is of connecting to one owned by the Bad Guys. I think this is BS - the enemy of anonymity is predictability and that's just what is happening here. Have you been compromised by NSA? I am going to stop using TOR
    – Fred
    May 16 '17 at 4:30
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

2

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

1

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.

1

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!
2
1

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)

1

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)

1
  • Hey, I merged your answer with another question so this answer is actually relevant to the question. This is why I removed the last sentence. Just wanted to give you a heads up.
    – Swangie
    Jun 3 at 14:28
0

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.

4
  • How do you imagine "hijacking" works? Relays can't impersonate other relays because they use authenticated key exchanges. A man-in-the-middle cannot impersonate a relay that they do not hold the private keys for. A relay they do hold the private keys for they already control. Hijacking isn't a meaningful attack.
    – cacahuatl
    Nov 6 '17 at 23:14
  • Don't have to imagine how it's done, since the issue is about whether or not "guard nodes" add to security and the preservation of anonymity. I'm unconvinced they do, and don't see a way to get there. In fact, I think Fred's point is a valid one and that they may go the other way. As a general rule I try not to begin by assuming there is no way to compromise something to justify a design decision. Nov 7 '17 at 4:57
  • "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." <- since this "hijacking" cannot happen, your speculation drawn from this possibility makes the whole point moot.
    – cacahuatl
    Nov 7 '17 at 11:30
  • Also, if you want "the mathematical analysis behind this policy" it's literally in the two links in the answer to this question. Which makes me think you did not bother to actually read it.
    – cacahuatl
    Nov 7 '17 at 11:33
-1

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.

-3

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.

1
  • Could you elaborate how your posting answers the question above?
    – Jens Kubieziel
    May 16 '17 at 8:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.