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

[s7r]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

Just to make sure you realize this puts you at higher risk in running
into a malicious guard. If you stick to the same entry guard for
longer time as Tor does by default, you have less chances to run into
an evil guard because you don't choose so often. If you run into an
evil guard your anonymity will be hurt badly. I can't say that a
malicious guard means 100% deanonymization, but for sure it's _very_
bad, so if you can choose less often it is better. That's why I always
recommend to stick with the default Tor settings, unless you have a
very good reason for what you are doing.

The type of attack you describe sounds like a path bias attack. It's a
known one (hard for an attacker to accomplish) and there is ongoing
work to make Tor only try a certain number of relays as Guards. If
none of them are reachable or fail too much, it will disconnect
entirely and shut down to protect the user.

There is nothing an attacker can do in order to make you choose his
evil guards. If he succeeds to keep a certain number of evil guards
running in the network, it's all about (bad)luck if you pick them or
not - that is why it's very important not to choose too often.

On 11/1/2015 2:47 PM, Felix wrote:
> O.K., I found a workaround, I edited the File start-tor_browser
> and inserted a command at the beginning, that deletes the
> State-File in /Data/Tor.
> 
> Thank you, Harmony...
> 
> 
> Am 01.11.2015 11:12, schrieb Tom van der Woerdt:
>> Felix,
>> 
>> 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.
>> 
>> 
>> Tom
>> 
>> 
>>> On 01 Nov 2015, at 11:10, Felix <felix.wiedenroth at gmx.de>
>>> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWNhL/AAoJEIN/pSyBJlsRwNIH/31ZEk8LzKe0ou01Hfn/I+8O
E2MXBth7Fr2rpMZYdkJbUvI5lPNvySz+eZ50Uo/xBWsy3X40+5u5//2S/9wU41b0
u9zRGMfIU7R9BTZUxMlXVVAl93ylC1dyFW9Fmjd7oz7UnJs3il1GA1+lBgCROD5B
0+m0hhd5ZXnPjBYQOIBui7p1JScsyWU2LcI+WwrAmUmLWX62MvX+IDmdDPVaN/5l
Mc0pUjuMGnStdGkiG9Wc5RzVggevFLZk+ePSpHWN8tn4cCuOv0b7Ym8iqgMpmrHG
tCZyY1gvVkr4R+ijbYPDS3iWa6ElfKJtgcZPkKm363T8XqCcropYlvIGVlniEgU=
=aSqx
-----END PGP SIGNATURE-----