Delivery-Date: Mon, 05 Jan 2015 11:15:07 -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.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,URIBL_BLOCKED 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 98DF21E033A
	for <archiver@seul.org>; Mon,  5 Jan 2015 11:15:05 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 4B15132B4E;
	Mon,  5 Jan 2015 16:15:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 0C5F432B32
 for <tor-talk@lists.torproject.org>; Mon,  5 Jan 2015 16:14:59 +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 UI28I-kIl0Bq for <tor-talk@lists.torproject.org>;
 Mon,  5 Jan 2015 16:14:58 +0000 (UTC)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204])
 (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id DD97F32AEB
 for <tor-talk@lists.torproject.org>; Mon,  5 Jan 2015 16:14:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org;
 s=mail2; 
 h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date;
 bh=Pxz5Fm6Pu1Zlul6eBgyOC/tMqs8KXDs5SrPlxgTcbAk=; 
 b=FvkXbnScfL46sG42Bfici1uUjWp1YvvC1QdF3qPofOmm+MMUjV/febTtiRoNKIzl9o/OjdMauprcXfaBJeBcSfdLtmTN8l0f5cvhACv3P9nrLoHvdOXeU+YIAgGqLrCrgXG5QkrMnzVjBLKCTu3tcjtZcvwfUSHX278tqpcTraI=;
Received: ; Mon, 05 Jan 2015 08:14:55 -0800
Date: Mon, 5 Jan 2015 08:14:55 -0800
From: Seth David Schoen <schoen@eff.org>
To: tor-talk@lists.torproject.org
Message-ID: <20150105161455.GN4490@mail2.eff.org>
References: <CAB=COR7iiKtvJhkBhar=hch287R0yDsDyW=vapBZJOZ+NqnfWg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAB=COR7iiKtvJhkBhar=hch287R0yDsDyW=vapBZJOZ+NqnfWg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [tor-talk] TOR issues
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="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

Hollow Quincy writes:

> Dear TOR community,
> 
> I spend some time to understand how TOR works. I still cannot
> understand some design assumptions. Could you please help me to
> understand some issues ?

I think some of your questions are based on misunderstanding the
difference between circuits that exit to public Internet services, and
circuits that terminate at Tor hidden services.  These are two separate
Tor features, and each circuit (that eventually reaches some service)
terminates in one way or the other but not both at the same time.

> 1) Who store the mapping Onion_URL to real IP ? How exit node know
> where to send request ?

Exit nodes aren't used for hidden services at all.  Onion URLs are only
used to refer to hidden services, which communicate entirely within the
Tor network and don't exit.  Most uses of Tor use exit nodes to reach
public services on the ordinary Internet, instead of using onion URLs.

The hidden service directory mapping is performed by the hidden service
directory. :-)

> 2) How to become Exit Node ?
> I understand that everyone can become normal node. If I become exit
> node even for some requests I can find mapping Onion_URL to real IP.
> Than IP of the page is not secret any more.

Everyone can become an exit node by declaring a non-empty exit policy.

That does allow them to monitor user communications and see where the
users are connecting.  In Tor's design this is not considered bad,
because the _identity_ of those particular users should still be hidden
(although it's potentially bad in some threat models, like when the
same adversary operates, or monitors, both the entry and exit points of
a particular user simultaneously).

Exit nodes (or at least their exit service!) are not used in any way
for contacting hidden services.  Hidden services and hidden service
users communicate entirely within the Tor network.  (Hidden services
themselves build Tor circuits in order to talk to their users.)

> 3) How the communication is encrypted between nodes ?
> RSA encryption is not resistant for Man In The Middle attack. (that's
> why when I connect to new SSH server I need to add public key of the
> server to trusted list).
> When I use TOR my request goes to Node1 and than to Node2. How can I
> establish save connection with Node2, when Node1 is between us ?

Each Tor relay has its own public key which it declares when registering
with the Tor directories.  The Tor directories confirm that they have
the same view of the relays on the network, and the relays' public key,
through the consensus mechanism.

That means that the Tor directories are something like certificate
authorities or PKI for the regular Tor relays.  You have to trust the
consensus of the directories to give you the correct public keys for the
relays you plan to use, so that no relay (or ISP) can perform an
undetected man-in-the-middle attack.

https://www.torproject.org/docs/faq#KeyManagement

> 4) Is there a single point of failure ?
> There need to be one central place where all IPs of TOR nodes are
> stored, so when I run my TOR bundle I go to this place and read node
> list and send requests using it. So if this place is down (for example
> because DDOS attract) new users will not be able to use TOR network.
> They will not find any TOR node.

The directory authorities, for some purposes, might be the single point
of failure you're looking for.  Since they have some redundancy, you
might not call them a "single" point of failure, but they could be seen
collectively as a point of failure because they need to be operating and
reachable in order for users to be able to learn how to connect to the
Tor network.

-- 
Seth Schoen  <schoen@eff.org>
Senior Staff Technologist                       https://www.eff.org/
Electronic Frontier Foundation                  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x107
-- 
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

