[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