Delivery-Date: Fri, 31 Oct 2014 00:02:12 -0400
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.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	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 121381E0CAC;
	Fri, 31 Oct 2014 00:02:11 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 2BA6C3181D;
	Fri, 31 Oct 2014 04:02:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id BB5CB3129B
 for <tor-talk@lists.torproject.org>; Fri, 31 Oct 2014 04:02:03 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at eugeni.torproject.org
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 HUA7cxf6C4Jk for <tor-talk@lists.torproject.org>;
 Fri, 31 Oct 2014 04:02:03 +0000 (UTC)
Received: from khazad-dum.seul.org (khazad-dum.csail.mit.edu [128.31.0.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "moria.seul.org", Issuer "moria.seul.org" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 979753126F
 for <tor-talk@lists.torproject.org>; Fri, 31 Oct 2014 04:02:03 +0000 (UTC)
Received: by khazad-dum.seul.org (Postfix, from userid 501)
 id 667B31E0CAC; Fri, 31 Oct 2014 00:02:00 -0400 (EDT)
Date: Fri, 31 Oct 2014 00:02:00 -0400
From: Roger Dingledine <arma@mit.edu>
To: tor-talk@lists.torproject.org
Message-ID: <20141031040200.GO35778@moria.seul.org>
References: <CAJwFvsWUsTVit2E21Pn9m8vwh6qPXtG31JJso8RRP3ULw84Ozw@mail.gmail.com>
 <1414680507.14332.1452.camel@miskatonic>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1414680507.14332.1452.camel@miskatonic>
User-Agent: Mutt/1.5.20 (2009-12-10)
Subject: Re: [tor-talk] Can Tor run over Tor?
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>

On Thu, Oct 30, 2014 at 03:48:27PM +0100, Lars Luthman wrote:
> > If so, has anyone ever thought about the pros/cons of this? Obviously, it's
> > exponentially more inefficient. But is it any more secure?
> 
> I have done it accidentally with a misconfigured transparent proxy that
> sent its own Tor traffic to its own transparent proxying port. It
> worked, though a bit slower (as expected).
> 
> I don't think it would be any more secure. The most serious publically
> known attacks against the anonymity of Tor users (browser bugs etc
> notwithstanding) are correlation attacks where the attacker compare
> traffic at the client end with traffic at exit nodes and see if it looks
> similar in timing and data sizes. A six-relay circuit (which is what you
> get when running Tor over Tor) doesn't change that at all.
> 
> An attack where the traffic is actually traced all the way through the
> Tor relays would be harder, but those are probably not the attacks we
> should be worrying about in the first place. And a longer circuit may
> circuit as well.

Right.

Also have a read through
https://trac.torproject.org/projects/tor/ticket/2667
for how we'd like to disable Tor-over-Tor one day to block an
attack (but there are tradeoffs).

--Roger

-- 
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

