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

Re: [tor-bugs] #10024 [Tor]: Close and open sockets on IP change, tracking

#10024: Close and open sockets on IP change, tracking
-----------------------------+--------------------------------
     Reporter:  grarpamp     |      Owner:
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:  Tor: 0.2.5.x-final
    Component:  Tor          |    Version:  Tor: 0.2.3.25
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+--------------------------------

Comment (by grarpamp):

 DisableNetwork 0|1
            When this option is set, we don't listen for or accept any
            connections other than controller connections, and we don't
 make
            any outbound connections. Controllers sometimes use this option
 to
            avoid using the network until Tor is fully configured.
 (Default: 0)

 That seems like it might handle the interface-post-change (wake tor up),
 but doesn't mention any interface-pre-change context (ie: put tor to
 sleep).

 I'd wonder about the reaction speed of application based 'magical
 discernment'.
 Whereas monitoring/handling a kernel provided OS API (an interrupt
 delivered
 to tor by the kernel), if one existed, would give instant change notices.

 I'm not sure if this is of much importance...

 Since the user was/is still behind encrypted hops to the guards. And the
 crypto would prevent mitm / games at the client to guard boundary. So
 the state/content itself seems safe there.

 If a user's IP changed while passing traffic as an exit relay,
 there might be some kind of minor issue there. The common case for
 that might be residential dhcp via cable/dsl/fiber. The ISP
 would surely have dhcp-to-residence-level logs, so that is moot.
 However whatever is beyond the ISP, such as the destinations
 of that exit traffic, should not be able to piece an IP change
 together. That is somewhat mooted if the relay descriptor keeps the
 same fingerprint/keys across such a change since they could poll
 that instead.

 Any monitoring-to-sleep/wake solution is moot if tor is behind a nat...
 it can't detect the farside ip change at the nat in time and so
 continues retransmitting through the nat till then, which happily
 nats it out. Only manual toggle would work there.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10024#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs