Delivery-Date: Thu, 23 Apr 2015 20:06:21 -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.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 0EC441E0A93
	for <archiver@seul.org>; Thu, 23 Apr 2015 20:06:20 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 5170834C9D;
	Fri, 24 Apr 2015 00:06:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id B62F034EEF
 for <tor-talk@lists.torproject.org>; Fri, 24 Apr 2015 00:06: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 JCay7u7zbHaQ for <tor-talk@lists.torproject.org>;
 Fri, 24 Apr 2015 00:06:12 +0000 (UTC)
Received: from smtp2.hushmail.com (smtp2.hushmail.com [65.39.178.134])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "smtp.hushmail.com", Issuer "smtp.hushmail.com" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 7B33034C9D
 for <tor-talk@lists.torproject.org>; Fri, 24 Apr 2015 00:06:12 +0000 (UTC)
Received: from smtp2.hushmail.com (localhost [127.0.0.1])
 by smtp2.hushmail.com (Postfix) with SMTP id 86D2AA01B3
 for <tor-talk@lists.torproject.org>; Fri, 24 Apr 2015 00:06:09 +0000 (UTC)
Received: from smtp.hushmail.com (w2.hushmail.com [65.39.178.46])
 by smtp2.hushmail.com (Postfix) with ESMTP
 for <tor-talk@lists.torproject.org>; Fri, 24 Apr 2015 00:06:09 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99)
 id 73C53E04DA; Fri, 24 Apr 2015 00:06:09 +0000 (UTC)
MIME-Version: 1.0
Date: Thu, 23 Apr 2015 20:06:09 -0400
To: tor-talk@lists.torproject.org
From: "l.m" <ter.one.leeboi@hush.com>
In-Reply-To: <55315DC9.50802@sophiehassfurther.com>
References: <20150416215238.37FBBC03DD@smtp.hushmail.com>
 <55315DC9.50802@sophiehassfurther.com> 
Message-Id: <20150424000609.73C53E04DA@smtp.hushmail.com>
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [tor-talk] TorBirdy seems to connect to the same exit node
	again and again
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>

Hi Sophie,

Hmm...Perhaps Atlas isn't the best choice here. At any given time the
exits you can choose from are those you know of locally. It might be
better to focus on TorBirdy instead. 

When using Tor Browser, the tor process is kind enough to take notice
when using certain ports (WarnPlaintextPorts). So maybe TorBirdy
should do the same. That is to say, make TorBirdy more verbose about
choices for mail server port. Had you been warned that port 25 is not
the port you're looking for you might have chosen differently. Even if
the port was chosen temporarily, a reminder could've helped. To make
things worse you have to switch between TorBirdy and Tor Browser to
change identities. Then you have to run something like
check.torproject.org to ensure your ip is different from a
(potentially blocked) previous ip.

So things TorBirdy could do better to avoid this problem in the future
include:
a) Be more verbose about choosing the mail server port. Possibly
include a reminder which can be disabled. Warn when making a hazardous
choice such as 25. A known abuse port and one which is blocked in the
default exit policy and reduced exit policy.
b) Provide new identity functionality in TorBirdy. It would need to be
careful not to "step on the toes" of Tor Browser. To this end it could
emulate the NEWNYM signal by leveraging stream isolation. New
identities triggered by TorBirdy would create streams isolated from
previous streams. By tracking streams associated with mail servers
TorBirdy can ensure old connections are closed before new ones. It can
do this in a way such that no interference occurs with Tor Browser.
c) Enable TorBirdy to configure use of TrackHostExits/Expire. Purely a
preference to deal with Tor Browser triggering a new identity when you
might prefer to have TorBirdy continue to use the last exit for a
time. If you've triggered a new identity in TorBirdy to avoid a
blocked exit this could also mitigate the problem of a blocked exit
being reused. Is there a better way to achieve the same result here?

Comments, suggestions, criticisms?

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

