Delivery-Date: Tue, 23 Dec 2014 18:24:21 -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_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,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 993941E0D05
	for <archiver@seul.org>; Tue, 23 Dec 2014 18:24:19 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 5E85E324F0;
	Tue, 23 Dec 2014 23:24:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id A5D6D324A0
 for <tor-talk@lists.torproject.org>; Tue, 23 Dec 2014 23:24:12 +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 E4eTA0xpY0yM for <tor-talk@lists.torproject.org>;
 Tue, 23 Dec 2014 23:24:12 +0000 (UTC)
Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com
 [IPv6:2a00:1450:400c:c00::236])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 483E332373
 for <tor-talk@lists.torproject.org>; Tue, 23 Dec 2014 23:24:09 +0000 (UTC)
Received: by mail-wg0-f54.google.com with SMTP id l2so10171305wgh.13
 for <tor-talk@lists.torproject.org>; Tue, 23 Dec 2014 15:24:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=user-agent:in-reply-to:references:mime-version:content-type
 :content-transfer-encoding:subject:from:date:to:message-id;
 bh=gVs4RZuQDX1NzIlwOqDF1eG1oHRseGRMdEjV/5pPNpo=;
 b=NVW74GN5FwO3/BpD1HnVoYLYILrxtPziLLfW6vuvq21x+o7SEDc/dZ46OwNe3Ht2zI
 4fHxHiFYypPQhC0lXSTyHy69yOLyVMT6sqzzw/QGiJTSnZIKzR0HfSDOFOMKqx5rzAmr
 zZXXcdmODJsziSKcAuv8tJ/Ey2549PIuqNQBHMjLwwhFKqLjKV1Wb7RnOfZ41ZdyPKGG
 YLGDfzX8RGvQC7W0LHn7+Ugqcf4zch6kzbKu+rL6DcUbkT9n34aL1QPekYRq0jZ4f3bz
 mnc/XmLrAkxrrLCDOxbtQv/XUrzvKcbXKEgv7F3D8s6FmcXbwK0BcY5ohGcuHKhvtm6i
 ZUMg==
X-Received: by 10.180.76.132 with SMTP id k4mr46434973wiw.41.1419377045821;
 Tue, 23 Dec 2014 15:24:05 -0800 (PST)
Received: from [10.183.76.254] ([80.12.39.254])
 by mx.google.com with ESMTPSA id h8sm19057275wiy.17.2014.12.23.15.24.03
 for <tor-talk@lists.torproject.org>
 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Tue, 23 Dec 2014 15:24:04 -0800 (PST)
User-Agent: K-9 Mail for Android
In-Reply-To: <5499C128.90100@enn.lu>
References: <20141219221905.GU8030@moria.seul.org>
 <54988708.9070806@riseup.net> <20141222211839.GF8014@moria.seul.org>
 <54989935.1020307@riseup.net> <5498A00C.70301@enn.lu>
 <5498A643.3070408@riseup.net> <5499C128.90100@enn.lu>
MIME-Version: 1.0
From: Alexis Wattel <alexiswattel@gmail.com>
Date: Wed, 24 Dec 2014 00:23:56 +0100
To: tor-talk@lists.torproject.org
Message-ID: <232B572C-98FA-4FBA-B75E-437DF20A60CE@gmail.com>
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [tor-talk] Possible upcoming attempts to disable the Tor network
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>

Hello, 

First I'd like you to know that I'm not deeply familiar with the internals of Tor infrastructure. 
However I'm reasonably confident to have grasped one fundamental aspect of this issue, being that Tor routing depends first and foremost on 10 servers. 

Because decentralizing this system will imply a major infrastructure evolution, I think that the priority for now is to find a quicker and temporary workaround. 

TL;DR: Straight facts are between the lines. 

Whatever be their ground, these threats seriously expose what could be a single point of failure for any capable adversary.
This attack would in my opinion inflict devastating damage to the Tor network, mainly because of a complete reversal of the psychological balance between Tor promoters and adversaries. (*) 

So 10 servers would need to be seized or compromised to launch this attack. 
For a legal seizure, the different jurisdictions to which those servers belong need to be studied at least a little, to determine how easy/hard it would be for a politically influent state to obtain cooperation from each and every local police force. 
As for an illegal compromise, the challenges are very different and a lot has to be thought about. 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

In a few words, here's what I thought could be a somewhat quick to deploy temporary defense plan. 
As the 10 DirAuths servers are hard coded, why not make use of that existing feature? I mean : 
Hard code several additional backup servers.
Those cannot directly be DirAuths servers themselves, because obviously the same problem would arise. These would be Gateway servers. 

The key is that they will be programmed to redirect users towards the backup DirAuths servers only once the backup plan has been activated. Before this happens, no one should possibly be able to learn the locations of the backup DirAuths from these public Gateways. 

To achieve this, the code that will manage the transition to the backup DirAuths will be encrypted. The backup plan will include the delivery of the needed cipher keys to these Gateways enabling them to now happily redirect users to fully functional DirAuths (whose location was not (supposed to be) known until that time). 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 
Legal actions to seize servers in different jurisdictions requires lots of preparatory work, meaning lots of time. It then appear possible to use this aspect to our advantage. 
A careful and knowledgeable examination of the different state jurisdictions concerning warrant authorization, or eventually known habits to bypass them, etc... could build a great basis on which to implement our beloved security-in-depth principle applied to the juridical world. It's all about multiplying the barriers... 

I think this strategy could build a powerful defense against an attempt to instantly knock down of the whole network using this discussed mean of attack. 

However, the major difficulty my suggestion would struggle against is that the complete deployment of these backup servers, especially the DirAuths ones, must be conducted with great stealth. 
It will take the most cleverly skilled hackers devoted to the Tor Project to adress this issue, issue that I once again consider to be a major one. 

Although laying this idea on the table could hopefully light up considerable improvement ideas to help any backup deployment to operate safely. 

Moreover, what are your thoughts on this short-term contingency plan? 

Respectfully, 
Alexis Wattel

* I'll elaborate on why I think that this attack could have serious adverse impacts on the Tor network if anyone whishes to discuss it. 

P.S.: This being my first contribution to a mailing list, I hope I got the citation formatting right! ;) 

> Tyler Durden:
>
>
>> > So is there no need for some more trusted dir authorities? I mean
>> > 10 for the whole networks seems a bit tiny.
-- 
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

