On Sunday 25 November 2007 02:23:18 anonym wrote: > On 25/11/07 02:54, Gregory Maxwell wrote: > > On 11/24/07, anonym <anonym@xxxxxxxxxxx> wrote: > > >> Even though we still get as much anonymity as Tor offers and netstat is > >> wrong in some way I really do not want this to happen. Incognito uses > >> TorK as a control GUI to Tor, and since its "Non-Tor traffic log" uses > >> netstat and thus will log these erroneous connections, users might freak > >> out and think that Incognito is unsafe. In fact, that was what happened > >> to me. Can this be fixed? > > > > Yes. Don't do that. > > > > it would be better if you were running something that sniffed the > > network and showed the user all outbound packets that were not TOR. Absolutely.The use of netstat for the gui (at the moment) is intended to alert the user to chronic non-anonmous traffic and is flagged in the gui as 'Not 100% reliable'. The use-case is: OK I'm visiting this site anonymously but is it generating stateful traffic I'm not necessarily expecting? That log window has been there since the year dot and can definitely be improved on. The simplest approach I can think of is a setuid libpcap-based program to replace the use of netstat. The word 'setuid' rings alarm-bells though and I would certainly welcome advice on how much harm such a thing could cause. (Installing an rc.d launched daemon is very hard to do in a (linux) platform agnostic way, so if someone is suggesting such an approach I would appreciated input on how to implement it properly). Would libpcap capture stateless/connectionless traffic though? > > That would be better but my concern is mainly with TorK, and it uses > netstat for its logs. I don't expect the average Incognito user to > monitor netstat, but they might very well find some misleading > information in Tork's logs (as they are very easily accessible through a > nice GUI and all). Well, I guess this is an issue with TorK. Hopefully > Robert Hogan (TorK's maintainer) will read this, although my problem > might be a bit too specific to justify a fix which I guess would turn > out much more complex than the current solution with netstat. > The 'real' solution is definitely still to be found. The information from netstat is misleading because it is using the /proc filesystem to gather that's, and that's at least one level up from the packet-munging taking place in netfilter (according to my simplistic understanding). It will always be misleading. Maybe even the info from libpcap would be misleading. Could you try out pktstat (which I learned of on #tor and uses libpcap) and see if the correct info gets reported? Another candidate is ip_conntrack, but again a root-owned daemon would be required. Anyone with wisdom to spare on this listening? > > Just looking at netstat may well miss short-lived (and especially > > connectionless) packets which are probably much more of a significant > > real threat to the user. Agreed. TorK tries to guard against these for the non-incognito user by providing two 'fail safe' options (DNS Failsafe, and 'System Failsafe') which route DNS and sensitive, ecnrypted traffic respectively through Tor. The traffic that's routed is configurable for both options. > > If I'm not mistaking, Tor circuits are long-lived enough to show up (?). The connection to the Tor server at the start of the circuit shows up there alright, and yes they are long-lived enough generally. > Or are you suggesting that Tor initiates other connections as some sort > of intermediate step (I'm certainly no expert on the inner workings of > Tor)? Perhaps I wansn't clear enough, but the only Internet traffic that > is allowed is made through Tor. Any way, I don't know exactly how TorK > uses netstat to generate its log (I guess it uses --continuous which > updates every second), but the entries in the log stay even though the > connection has been disconnected (and netstat stops showing them). Yes, it's intended as a record of your session, but is not retained between sessions and can be cleared at any time. > > Connectionless packets is not a problem as only TCP is allowed to leave > the computer since UDP etc., as you pointed out, might be a real threat.
Attachment:
signature.asc
Description: This is a digitally signed message part.