[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Question Regarding Routing of Network-Traffic using Tor-Browser


Guards' network speeds are assessed based on the view of the network, not the client. What this means for your North Korea example is that the government couldn't affect path selection by slowing down the network, as Tor will still pick the same guards. 


> On 01 Nov 2015, at 11:10, Felix <felix.wiedenroth@xxxxxx> wrote:
> Hello,
> I read the linked Page and understand most of the ideas behind the concept of using only a few number of Entry-Guadrs. However, as I understand Entry Guards are chosen by Parameters like Response-Time or Network-Bandwidth.
> If  i.e North Corea. would like to control the Tor-Network in NC, NC would have to do the following things:
> 1. Slow down (or disable) the rest of the Internet from outside NC extremely.
> 2. Setup some fast Tor-Servers (Primary Entry Guards) inside NC.
> 3. Provide fast Tor-Relays (inside NC) that are accessible from these Entry Guards (other Tor-Relays are slow from or inaccessible these Entry Guards)
> 4. Provide (fast) Exit-Nodes inside NC.
> In this scenario the fast Primary Entry Guards would proably the chosen for almost any Network-Traffic using Tor, and I could at least see which IP-Source-Adresse would bei using Tor.
> If the rest of the Tor-Network would rely on Performance-Data for Routing the Traffic, NC could proably also see the Tor-Relays (and maybe even the Exit-Nodes) - so Tor would be (somehow) useless.
> So in my opinion it would be at least a good (configurable) option to provide dynamic switching of the Entry-Guards - as this would at least make it more difficult to trace every move of a Tor-User.
> Regards,
> Felix
> Am 01.11.2015 02:24, schrieb Harmony:
>> Felix:
>>> Hello,
>>> I am from Germany and I use the Tor-Browser very often. I think Tor is a
>>> great product.
>>> I have a question regarding the connection from my Tor-Browser to the
>>> Tor-Network.
>>> I noticed, that Tor tends to always connect to the same Tor-Relays on
>>> the internet. I can observe this when I monitor the connections using
>>> Netstat on my Linux-machine - even after restart of the Tor-Browser or
>>> even after a reboot of the Linux-machine.
>>> So my initial Idea was to delete the "cached*-files" in the
>>> /Data/Tor-Directory before each start - but this does not help - Tor
>>> always connects basically to the same Tor-Nodes all the time. I think
>>> this is probably due to an internal "ranking" in the Tor-Network.
>>> So my question is, would´nt it be better (or more secure) for the
>>> End-User, if the Tor-Browser (or the Onion-Router) would change the used
>>> Tor-Relays i.e. every 5 minutes. As the Tor-Browser connects to more
>>> than one Tor-Relay, this could be staged, Drop Tor-Relay 1 after
>>> connection to Tor-Relay 3 has been established i.e.
>>> Are there any plans to enhance the Tor-Network / the Tor-Browser in this
>>> direction?
>> Hello Felix,
>> https://www.torproject.org/docs/faq#EntryGuards
>> This is in fact a safety mechanism that Tor uses, as explained in the
>> above link. If your browser connected to new 'first-hop' relays every
>> time, there would be a greater chance that one day all the relays in
>> your circuit are attacking you. By picking one (or a few) guards only
>> and cycling them rarely, it is that much more tedious for anyone who is
>> waiting until you pick their bad relay in order to attack you.
>> Tor certainly did at one stage change its circuits after ten minutes, as
>> you suggest, but for various reasons this was altered, and in any case
>> Tor Browser itself manages circuits in a different way to the core Tor
>> program. It's a much-discussed question and no one yet has the perfect
>> answer.
>> If for some reason you really do need to change the guards that your
>> browser is using, the file to delete is called 'state', and it is under
>> Browser/TorBrowser/Data/Tor (on Linux). Generally, however, you should
>> not do that.
>> [I am not an expert on any of the above.]
>> Thanks,
>>> Thank you very much.
>>> Regards,
>>> Felix
> -- 
> tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to