> On Thu, May 10, 2012 at 10:11:06PM -0400, johnmurphy...@safe-mail.net wrote: > > IN= OUT=eth0 SRC=192.168.178.50 DST=some-target LEN=40 TOS=0x00 PREC=0x00 > > TTL=64 ID=0 DF PROTO=TCP SPT=50447 DPT=443 WINDOW=1002 RES=0x00 ACK URGP=0 > > > > This packet is https, most likely generated by my firefox user when > >I was browsing a website. But it gets more interesting. There are lost > >packets, even when I only use Tor. A reverse dns lookup of the target > >ip shows that these are packets send by tor to the first relay. > > These statements are contradictory. If the destination is a Tor relay, > and the destination port is 443, then it's a Tor relay whose ORPort is > 443. (Many relays listen on 443 so they can be reachable by firewalled > users.) Your firefox user probably has nothing to do with it.
The tor packets (or at least what I think what tor packets were) went to another port, of course. > > How is it possible for a packet not to have an associated uid? > > This I do not know. > > It does sound like your iptables failing to categorize the packet, > rather than an actual application-level leak, though. Of course. Application-level leaks (I have those as well :( ) have associated UIDs. Here is the relevant except of the iptables output: -nat: No rules associated with my firefox user (I do not want to forward its packets through tor) -filter OUTPUT: ... 0 0 RETURN all -- any any anywhere anywhere owner UID match firefox-unsafe ... 45 2340 LOG all -- any any anywhere anywhere LOG level warning tcp-options ip-options uid prefix "DROP " 45 2340 REJECT all -- any any anywhere anywhere reject-with icmp-net-unreachable Any ideas? _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk