[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Stricter NEWNYM?



On Sun, 20 Mar 2011 05:13:39 -0500 (CDT)
Scott Bennett <bennett@xxxxxxxxxx> wrote:

>      On Fri, 4 Mar 2011 10:17:30 -0800 Robert Ransom <rransom.8774@xxxxxxxxx>
> wrote:
> >On Fri, 04 Mar 2011 13:21:22 +0100
> >anonym <anonym@xxxxxxxxxxx> wrote:
> >
> >> While I've been developing the LiveCDs Incognito and Tails I've got my
> >> fair share of feature requests/bug reports that really are about Tor.
> >> One recurring feature request is to make NEWNYM stricter.
> >>=20
> >> Users have observed that issuing a NEWNYM doesn't necessarily stop using
> >> the previous circuits, which is obviously the case for truly long lived
> >> connections like IRC and SSH, but I don't think that is what bothers
> >> them; web browsing connections also keep using the old circtuits, at
> >> least with certain web browser and intermediate proxy configurations
> >> that makes them "kinda" long lived (think http keep-alive timeouts).
> >> This confuses users when they get the same exit node after a NEWNYM (for
> >> instance by refreshing check.torproject.org afterwards).
> >
> >This can happen even on a new circuit.  Tor does not try to select a
> >different exit node after a NEWNYM has been issued, as that would make
> >users' streams before a NEWNYM more linkable to their streams after the
> >NEWNYM.
> >
> >> Conclusion: NEWNYM doesn't do what the users expect.
> >>=20
> >> That's no good. Why don't we make NEWNYM ruthlessly kill all circuits,
> >> even the ones handling live connections, long lived or not? I strongly
> >> believe this stricter NEWNYM behaviour is (at least closer to) what the
> >> user expects from it. See the attached patch for a quick and dirty
> >> implementation -- a patch says more than a thousand words, I suppose.
> >>=20
> >> Of course, to use NEWNYM requires some caution from the user, e.g.
> >> clearing cookies, session id etc. if revisiting the same site, but that
> >> also affects the old NEWNYM approach. Maybe it's even the case that
> >> NEWNYM gives a false sense of a new identity, given all application
> >> level problems that Tor cannot (or at least shouldn't) do anything
> >> about, and thus we should give a shite?
> >
> >Torbutton would also need a 'new identity' button.  See
> ><https://trac.torproject.org/projects/tor/ticket/523> for some
> >discussion of what that would involve.
> >
> >If you want to close all web-browsing streams while switching to a 'new
> >identity', the best currently possible options are to toggle Torbutton
> >off, then back on, or to quit Firefox entirely and restart it.  (This
> >also requires that you restart Polipo or not be using it.)  Perhaps
> >that should be documented better.
> >
> >Alternatively, a user could use Vidalia's 'Network Map' to close all
> >open web-browsing streams.
> >
> >>                                         In any case, are there any new
> >> problems introduced by this more brutal approach that I haven't thought
> >> of which would make it worse than the previous one?
> >
> >This approach would make it impractical for a user to use IRC or SSH on
> >a LiveCD while browsing without linking the IRC/SSH session to
> >his/her/its browsing activities.  Please separate the 'kill all
> >streams' command from the NEWNYM command.
> >
> >A 'kill all streams' command would be more useful if it came with an
> >implementation of proposal 171 and ended all streams sent by one
> >application (as determined by the application-separation criteria in
> >that proposal).  Unfortunately, that won't become possible until
> >proposal 171 is implemented.
> >
>      Recall that UNIX and LINUX systems are inherently multiuser systems.
> Even if many are not actually used by more than one person, many others are.
> A "kill all streams" command would therefore need to be restricted to use
> only by the system administrator or perhaps a small group of users allowed
> such power over all users who might be using the tor client at the time.
> Otherwise one user could disrupt the work of many other users very easily.
> 
> 
>                                   Scott Bennett, Comm. ASMELG, CFIAG
> **********************************************************************
> * Internet:       bennett at cs.niu.edu                              *
> *--------------------------------------------------------------------*
> * "A well regulated and disciplined militia, is at all times a good  *
> * objection to the introduction of that bane of all free governments *
> * -- a standing army."                                               *
> *    -- Gov. John Hancock, New York Journal, 28 January 1790         *
> **********************************************************************
> _______________________________________________
> tor-talk mailing list
> tor-talk@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Someone who can issue controller commands can already close other streams, e.g
via the CLOSESTREAM command.

-- 
Please use encryption. My PGP key ID is E51DFE2C.

Attachment: signature.asc
Description: PGP signature

_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk