Testers wanted! New FIN ACK / RST ACK Leak Test - Part 2

Development
1

Here’s what I believe is going on. By using tcpdump with paramter: any host, it gives me a view of every packet generated anywhere on my machine that is headed to google, even those that are traversing the inner isolated network. Even those that are not necessarily travelling from my real host nic across the clearnet. I figured this out by using netstat -natp , more details below.

So this instruction in the leaktest would be wrong for KVM testing IMHO:

On the host.

Check, that you can not see any connections to 74.125.28.104 in tcpdump.

As for the TCP flags and such in the tcpdump logs, I think that there is a mistake with the way I am interpreting the results of this test. I want to post logs, sanitized ones though, that will let us both get to the end of this.

Transproxy enabled default config:

When relying on netstat -natp on the host, I haven’t seen any packet heading towards google or showing a connection between my host ip directly to google.
Here;s what I see instead, Just the Gateway listening on eth0 and a bunch of python connections from localhost 127.0.0.1 headed to a second column of localhost destination 127.0.0.1.
Again, I will post these logs if you need to know more

On workstation netstat -natp output before shutting down Tor and interrupting connection:

Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:9050 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:9051 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:9150 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:9151 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:11109 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:9151 127.0.0.1:33412 TIME_WAIT - tcp 0 0 127.0.0.1:9151 127.0.0.1:33414 TIME_WAIT - tcp 1 0 192.168.0.11:35406 74.125.28.104:80 CLOSE_WAIT 6767/python tcp 0 0 127.0.0.1:9151 127.0.0.1:33406 TIME_WAIT - tcp 0 0 127.0.0.1:9151 127.0.0.1:33408 TIME_WAIT - tcp 0 0 127.0.0.1:9151 127.0.0.1:33410 TIME_WAIT - tcp 0 0 127.0.0.1:9151 127.0.0.1:33416 TIME_WAIT - tcp 0 0 192.168.0.11:40537 192.168.0.10:9108 ESTABLISHED 8343/curl.whonix-or tcp 0 0 127.0.0.1:9151 127.0.0.1:33402 TIME_WAIT - tcp 0 0 127.0.0.1:9151 127.0.0.1:33404 TIME_WAIT -

After restarting Tor and doing s close:

Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:9050 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:9051 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:9150 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:9151 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:11109 0.0.0.0:* LISTEN - tcp 1 1 192.168.0.11:35406 74.125.28.104:80 LAST_ACK -
2

Patrick I read the Tor mailinglist more carefully. I wish done so ages ago and saved myself a lot of effort. The instructions you posted for the leaktest are problematic and caused this confusion, because they look for packets from all network interfaces on the host, even the virtual ones. So no matter what, there was always going to be packet showing up in the tcpdump log ,because tcpdump was told to look for them. Simple as that.

So instead I ran tcpdump with the parameters recommended by Mike as such that it only looked for packets from the hosts physical wifi device:

sudo tcpdump -n -i wlan0 host 74.125.28.104 and tcp port 80

and nothing showed up in tcpdump at all. Nada nothing. This means that with the default settings with transproxy on and without the proposed fixes in the experimental repo, nothing leaks to expose users. I am confident and I know what I did this time. Whether you wish to add the new settings to the firewall just in case its up to you. You might as well since you wrote it now.

Sorry for the hassle, I should have been more careful and read the original thread with more attention.

So what remains are two things, to change the leaktest settings to this command above instead, as to not baffle any one else in the future and to cross this off the blocker bug list. Should I cross post this in the original FIN ACK thread?

EDIT:
I corrected the wiki for the leak test and posted the instructions straight out of the mailinglist message.
https://lists.torproject.org/pipermail/tor-talk/2014-March/032503.html

Replace '-i wlan0' with your network interface. If you use '-i any', you will also see transproxied packets (which are not normally leaked).
3

Did a follow up test this time tcpdump ran on gateway and sniffed for packets on eth0. Nothing came up in logs both with and without the firewall fix. default settings of Transproxy enabled of course. :smiley:

Case closed

4

Great finding! Seems like VirtualBox implements the virtual interfaces other than KVM.

I guess to be even more certain, we should run our traffic through physically isolated Gateway (non-Whonix!) and run tcpdump there on all interfaces.