Delivery-Date: Sun, 01 Nov 2015 05:23:52 -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 CA2231E027C;
	Sun,  1 Nov 2015 05:23:50 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 6772C387B2;
	Sun,  1 Nov 2015 10:23:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 50653387AF
 for <tor-talk@lists.torproject.org>; Sun,  1 Nov 2015 10:23:40 +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 VNDWPuATw37w for <tor-talk@lists.torproject.org>;
 Sun,  1 Nov 2015 10:23:40 +0000 (UTC)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21])
 (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 221D6387AE
 for <tor-talk@lists.torproject.org>; Sun,  1 Nov 2015 10:23:40 +0000 (UTC)
Received: from [0.0.0.0] ([77.247.181.162]) by mail.gmx.com (mrgmx103) with
 ESMTPSA (Nemesis) id 0M9bYB-1ZlNGp1kER-00CwUq for
 <tor-talk@lists.torproject.org>; Sun, 01 Nov 2015 11:23:37 +0100
Message-ID: <5635E831.4000305@gmx.de>
Date: Sun, 01 Nov 2015 11:23:45 +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:8FTTG3N7sBULIPls30XPLot0YcaEJxEauW3dK38O0Kl+QBXa2rI
 KjAxY89e8RhihtX3Rmx2wFtGq0KxF3VdKO4hC++i225/lB0ok4mozkh05alPcGNWe6NQcLq
 zTzXK+13coXmlpkdRd4/yBkdnu2+wnEfGUPrKDjrwZmE3g6G1mMsuXZgEtfWryQaZMgNIeS
 bmfz3wIRwR/eGVS4ZdEaA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:guTanf7gL5A=:7wO8muW1hm/UWxWGcKLl1m
 v6QluX4zky9BhBPV19tLL4dysXDZJRrBQ6kABNJ62VgPb5xZ1aog7LTR2qrVWhAqkCTjN2d8z
 3xz9ecRNzCYygWL5QknaNvOl/0fntIDAZmR1pZJhM+YqYBzeawpxIZPqB5piIBADgDYgASxgc
 AFJ8MTbqx7EY4uzRf4Agq0gSJfjJWcXUPv0DB5PAVrqAaPs2Hb0YsLEu71gYy/EX17dLGd3dp
 8Wg8b7sWm06CfQlw0csRzhsMRAF/PhoVR7sS20qQtQCVt3d66aEdsKq5bYKXkYsvxqO49MYOZ
 THN6YrQqD1BMtAjAOl0XzJiPE8mzegDSaPxHpHlD/2/a/OZJTr2LTxxtwDvVZ++3WVsSCcqvd
 1AdUZ1geda2vTCtN9QBp08bREdht0Fl/Od2DtbA5kBMi66MIgF68+HqpcimvVhYlUmis2XzoZ
 XH7c7ounf/z66c2jFtYMOhhF+PfmOkvKN+f36Ij2APIuoc7yxIyW+eNCf1r5u/fFg1NVdpgXW
 z1uyxoSoblbAgSuKVsIsdS0bCJqfkaHvuVbOmK7ZPMRgxiQY61DgaZtZKUqhyE+R/OfTt4mLm
 yd0vkdyjxD5ISnweUNUTyXfnV3/d82eTxdyJbzy6DIrZSpwzvjyIifoj6pxDLgtZO30BenRjq
 WUTgZqNs0vGmLwM/CMb+39k9hDmk+xN5Fy0rmqX/wrpVXtPuFx6c99ADQja+ebXUG4MDz6BOy
 vCwFh7e90ToALU3Gkom54mTSf3u0mN1jkOTJeEAcmcjKOqkqGw5mQFyhm4e8nhtWlsdAR1VPl
 hP7oq/jkeExolX+fqUKzOe1oVs2Y1YjGASngcGt+jA3tnA7vqeQy0NkqKroVOTLel/QX22Nya
 dfml7/7U13Dt1QdoK6H7ZEmHXCknUaH8idJVhicKer+8jT7Zet7nrxqWV4QCj1+Tniu+XbzYf
 NMhMRm4lWzFq0jA8mLlXN+tQaoRyU++Vz9nKMoLgOLd0F9gn56BJ2
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., so if the Guards that are used are based on the view of the
network, this means NC knows which Entry-Guards are accessed from users
within NC, so the next approach would be to fake these Entry-Guards
(IPs) from within the country (Lets setup a Tor-Node inside NC, that
uses the same IP as the Tor-Node that would be accessed from outside NC)...

Isn$B!-(Bt Kim Jong-UN a smart guy somehow? ;-)

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

