Delivery-Date: Wed, 27 May 2015 14:20:58 -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.1 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,T_DKIM_INVALID,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 0303F1E1279;
	Wed, 27 May 2015 14:20:57 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id B78C0359A7;
	Wed, 27 May 2015 18:20:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 3EAF5359A4
 for <tor-talk@lists.torproject.org>; Wed, 27 May 2015 18:20:48 +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 bHr_sHk6ZwGJ for <tor-talk@lists.torproject.org>;
 Wed, 27 May 2015 18:20:48 +0000 (UTC)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com
 [IPv6:2a00:1450:4010:c03::22d])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id D4004359A3
 for <tor-talk@lists.torproject.org>; Wed, 27 May 2015 18:20:47 +0000 (UTC)
Received: by labpy14 with SMTP id py14so2013063lab.0
 for <tor-talk@lists.torproject.org>; Wed, 27 May 2015 11:20:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :content-type; bh=Pcngq/HuXMnR8eGQYfbr5qda2h/eXxzjMUU3hb0nIdc=;
 b=J+8U3TI0cM7sQzgqoY3GtoD1qnf6SMWdbidyoZe8HcHLIutqaPwCG5pmCcDIAl8WZn
 1+HQ56hCDP92IY1/Vf24AQP+FBKaVf2tPXL0nE1qX3q5UuVmZqkqaT9tKZbdftr3YVFp
 I7VysMVv2VofwyMOwDjCOMyll7SZ4NX6gAzMJ53Ba0pxSwKzqa/IXNkTMZ3GrRvFFXym
 CYAVxRDvEpUGyEh8ykwH50TFV7dtryFkfhZhUomQu5TcNM3L9/57Y5z97wmOcnDuc1p6
 W8db7Fz9oKVX7V4Ti8P9zF76TF77XqehAAqt4D5tsyfn+TfLOvJcXCROvS/Kb4XHPku/
 X7sg==
MIME-Version: 1.0
X-Received: by 10.112.199.35 with SMTP id jh3mr26998952lbc.23.1432750844704;
 Wed, 27 May 2015 11:20:44 -0700 (PDT)
Received: by 10.25.90.65 with HTTP; Wed, 27 May 2015 11:20:44 -0700 (PDT)
In-Reply-To: <02a901d0987b$a01eb230$e05c1690$@gmail.com>
References: <02a901d0987b$a01eb230$e05c1690$@gmail.com>
Date: Wed, 27 May 2015 11:20:44 -0700
Message-ID: <CAJVRA1QnA=fBV3=-i3NCL96JaDxtHvP4HksXmOE4GAvwMRqdVw@mail.gmail.com>
From: coderman <coderman@gmail.com>
To: tor-talk@lists.torproject.org
Subject: Re: [tor-talk] isolating multiple server requests
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 5/27/15, Allen <allenpmd@gmail.com> wrote:
> I have a client application that Tor to communicate with several servers.
> For privacy reasons, it is important that after each request, the client
> starts with a "fresh slate" so the server is not able to tell that the next
> request is coming from the same client.

ok, this is "stream isolation" and supported, as you discuss.



> 1. The client can make a new connection to the Tor proxy with a new unique
> username, see
> https://gitweb.torproject.org/torspec.git/tree/socks-extensions.txt.  My
> concern here is that over time, the Tor proxy will build up a long list of
> prior usernames that are never going to be used again.

you can expire out oldest, but i don't think you'll find this a
problem in practice.



> 2. The client can send Tor proxy a NEWNYM signal on its control port.

right; this is a big hammer - more than just isolation, although it
can be used to enforce isolation forward.


>  My concerns here are that:
> a. The spec implies Tor proxy might ignore that signal, see
> https://gitweb.torproject.org/torspec.git/tree/control-spec.txt

you can use stem to manually control / cull circuits and streams, too.
a back-up plan, perhaps.



> b. It is not clear to me how to be certain when the request has completed
> and it is safe to attempt a new connection.

right - you'd need to look at actual circuits via control port to know
for certain in all circumstances.



> c. That would reset circuits to all servers, including some circuits that
> might be in use.  While I don't think that would result in an error, it
> would slow down those requests and make Tor do unnecessary work to
> reestablish circuits.

right; also trade-off's involved.



> 3. The client can somehow talk directly to the Tor controller to establish
> new circuits.  My concern here is the complexity and potential to make a
> programming mistake that leads to information disclosure.

some Tor control port consumers restrict to only a few necessary
commands - thus eliminating the truly ugly and trivial attacks against
your anonymity using the control port against you.

stem is a nice python interface to do what you want. it is adding
complexity, but implemented thoughtfully the benefit would outweigh
risk.



> What is the best approach in this situation?

see also options:
IsolateClientAddr, IsolateSOCKSAuth, IsolateClientProtocol,
IsolateDestPort, IsolateDestAddr, etc.

note that potentially only on by default are: IsolateClientAddr,
IsolateSOCKSAuth

there is also a trac,
 #16004: Support Isolation by SCM_CREDENTIALS / SCM_CREDS for AF_UNIX
endpoints - https://bugs.torproject.org/16004 which may be relevant to
you.


best regards,
-- 
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

