Delivery-Date: Mon, 13 Apr 2015 13:16:07 -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 350A51E103A
	for <archiver@seul.org>; Mon, 13 Apr 2015 13:16:05 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id AB69833DEC;
	Mon, 13 Apr 2015 17:15:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 135823333A
 for <tor-talk@lists.torproject.org>; Mon, 13 Apr 2015 17:15:55 +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 KMaAFSWEZ-8v for <tor-talk@lists.torproject.org>;
 Mon, 13 Apr 2015 17:15:54 +0000 (UTC)
Received: from smtp10.hushmail.com (smtp10.hushmail.com [65.39.178.143])
 (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 C88622A9F9
 for <tor-talk@lists.torproject.org>; Mon, 13 Apr 2015 17:15:54 +0000 (UTC)
Received: from smtp10.hushmail.com (localhost [127.0.0.1])
 by smtp10.hushmail.com (Postfix) with SMTP id 1F322C017B
 for <tor-talk@lists.torproject.org>; Mon, 13 Apr 2015 17:15:52 +0000 (UTC)
Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52])
 by smtp10.hushmail.com (Postfix) with ESMTP
 for <tor-talk@lists.torproject.org>; Mon, 13 Apr 2015 17:15:52 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99)
 id E4E4BE042D; Mon, 13 Apr 2015 17:15:51 +0000 (UTC)
MIME-Version: 1.0
Date: Mon, 13 Apr 2015 13:15:51 -0400
To: tor-talk@lists.torproject.org
From: "l.m" <ter.one.leeboi@hush.com>
In-Reply-To: <552AFCCA.6040609@rawbw.com>
References: <5527BB80.8010708@sophiehassfurther.com>
 <20150410183853.GA32173@riseup.net> <552820C1.8050203@sophiehassfurther.com>
 <20150410215018.F057CC0D3A@smtp.hushmail.com>
 <5528C834.7020305@sophiehassfurther.com> <552AFCCA.6040609@rawbw.com> 
Message-Id: <20150413171551.E4E4BE042D@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 Yuri,

"Yuri"  wrote:
>I suggested adding new signal to also terminate old
>connections. 
>https://trac.torproject.org/projects/tor/ticket/15660

The problem of closing the connections gracefully is generally left to
the application. In tor's spec it's explicitly stated that it's the
responsibility of the application to gracefully handle connection
failure. In Tor Browser, and every other browser for that matter,
there are exploits that can leave unclosed connections. Tor Browser
deals with this by explicitly closing the connections associated with
a tab, for all tabs. This works as expected--allowing dirty, but
unused circuits to expire (also gracefully).

The problem with the feature that you propose is that it breaks a
major functionality of Tor. By default all traffic directed at a
particular socks port shares circuits. This means that all
applications that use, say, socks port 9150 will have their
application streams mixed together. This can help in some (limited)
ways to obfuscate the traffic. For example, an exit has no way of
knowing how many clients are sharing a Tor instance. The exit only has
the unique circuit id to say the streams are related in some way.

Explicitly closing circuits completely would break third-party
applications in unpredictable ways. It would generate errors that
would lead to posts to tor support describing weird application
behaviour. On the other hand explicitly closing application related
streams requires tor to be aware of the processes using it. Which
means additional logic to handle not just source port per application
stream but also source address (for the shared tor instance). If
you've seen the backlog of tickets you would understand why a major
change like this is not ideal.

If there's a problem. Either of applications not closing the
connection, or a server not closing the connection. These are problems
that should be fixed--not hidden by tor. That isn't to say what you
propose isn't a good idea, just it might be better left to custom
controllers. I think tor-devs might prefer to avoid feature creep.
--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

