Re: [tor-talk] TorBirdy seems to connect to the same exit node again and again

["l.m" <ter.one.leeboi@xxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk