Delivery-Date: Sun, 01 Nov 2015 07:48:00 -0500
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	RCVD_IN_DNSWL_MED,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 127C31E01A6;
	Sun,  1 Nov 2015 07:47:58 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 25FE63876A;
	Sun,  1 Nov 2015 12:47:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 12DE038738
 for <tor-talk@lists.torproject.org>; Sun,  1 Nov 2015 12:47:50 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id SBDeC7qsCUsL for <tor-talk@lists.torproject.org>;
 Sun,  1 Nov 2015 12:47:50 +0000 (UTC)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22])
 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id D4EEA386D9
 for <tor-talk@lists.torproject.org>; Sun,  1 Nov 2015 12:47:49 +0000 (UTC)
Received: from [0.0.0.0] ([194.150.168.79]) by mail.gmx.com (mrgmx102) with
 ESMTPSA (Nemesis) id 0MOTRh-1ZnfNc2Mmj-005mRG for
 <tor-talk@lists.torproject.org>; Sun, 01 Nov 2015 13:47:46 +0100
Message-ID: <563609F9.3090209@gmx.de>
Date: Sun, 01 Nov 2015 13:47:53 +0100
From: Felix <felix.wiedenroth@gmx.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: tor-talk@lists.torproject.org
References: <56355A1B.1000508@gmx.de> <563569E0.4000407@riseup.net>
 <5635E50E.3020700@gmx.de> <FF93C1E5-6493-4C7F-8369-A4F7B42E8633@tvdw.eu>
In-Reply-To: <FF93C1E5-6493-4C7F-8369-A4F7B42E8633@tvdw.eu>
X-Provags-ID: V03:K0:Q5zv2JruIAFNrvhs757wPodB0wLl9gVoHHchN8HXIcPNn71sNus
 wlxrgeWKvbX68zhSd7k2CDBA6upLQj57T95XEw1h3nHQyxFxDT1Ds62ukCCxOFRXZ3Zvsk5
 jMxLBFBrRp0UqmgQA77hqipGUEpyu/io3kU5n0TG4TcSDWPkBalvhv7+RwLD/pJnDbS5UZA
 pSIZvxfP5ylpm1SQhCz9g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:x3yzAw3wPGw=:1xGHaZ4WyZWiVZ0mQ0E9rq
 aZ1kyCtUK2hHjGKXZfdIORpjAkE0DikWn7M77KHeH4VGwnTIyUZpVXf8ox8KvxlFKy9fHrSaa
 /tREjcyZojftSWxgws6+poBj7tTe1Qe/IOPvQrQ3ZcgRZAQlqFrDOp0MRdMfpMAMgzkDRt8ei
 7slX6IRmhE1h+k1JsxO4iqB8ARrVvzjFaeCMKp7qh9io9L9szAgsNtisNLyBrWshcxwd3Hn+n
 xuWVJ5ctDZbT7PDN69PpvWte3TI7sKrQtAjl2zsSe+gf3tax0cXNsLldKHJBtWwuSwXx8bhGZ
 orTukxFThKUE3YQC2Bssb0CUSUuoTZDbOX7wzp0kPKfhUTA0SZyB0XMJbdMBUQye38XL1KhDw
 ib5c69/RUbzL4Yl5FYsWBLj6EIsay46EQLeJAY92p4uLdPXvZcGNdUT/d7pyhV1AxRGHx9e8u
 siei/eCMsLDM8Et8/VLGXyN4G4L1JZFhQ+/mUFQZi/qoOty/3MD0EtkSVQ1U0qvw9Hfv7KRhF
 1d53RW9KA5eA+X+5TSgJ8Wmrr8vD9kHdWUvR8ARCrrsWchja16sg3ZBK6mfsC/qvh9bpYZEEL
 w8m6byW+uyuiwVvo+/RHK85y3vAVBqGqqgoeDelg/eC69kNiIjcCcACUTOP0Z7rCNgzwd4i0P
 94UJf2eS2B2S2v4S+HeS+XdCjWEFdE4BNWttXow1xdikYHjjbbR7gX+N5VUxV8Cwyx/vN+THJ
 pFRm9ZR8A+YQ33odtT5gU5QzlPdMukhmLOp2mioIU3PvnAm46hwkbjO8zq+hd5WkkP2kNqjEd
 4x40HZ8pzHJyUPmOc8tfc3TI0QCvg==
Subject: Re: [tor-talk] Question Regarding Routing of Network-Traffic using
 Tor-Browser
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

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@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$B!-(Bnt 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@lists.torproject.org
>> To unsubscribe or change other settings go to
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

