Leak Tests

From Whonix
< Dev
Jump to navigation Jump to search

Major leak tests for for IP/DNS Leaks. How to check if this application is leaking? How likely that application is leaking? Unsuitable Tests: Location Detection, Operating System Detection.

Introduction[edit]

This wiki page lists and document all major leak tests.

Common Questions:

  • How to check if application is leaking?
  • How likely application is leaking?
    • Note: Replace application in above question with an actual application or activity.

Generic Answer:

Unfortunately, leak testing is as complicated as programming. One cannot learn it in a short period of time and it is highly unlikely to find an online volunteer teacher. It is infeasible for the Whonix project to educate everyone in the depths of networking.

Knowledge assumed[edit]

Leak Testing Websites[edit]

Read first! → Browser Tests

There are too many websites for leak testing. (Some are offline.)

None of the Leak Testing Websites running inside Whonix-Workstation™ is able to find out the real external clearnet IP address, no matter if plugins, flash and/or java are activated.

DNS Leak Tests[edit]

Online[edit]

Deactivate host DNS[edit]

Deactivating the DNS on your host should result in not being be able to nslookup anymore, but Whonix-Workstation nslookup should still be functional.

Theoretical background: Whonix-Workstation requests should always be resolved by Whonix-Gateway™. In the case of a DNS leak, the host operating system is resolving DNS queries for the Whonix-Workstation. Deactivating the host's DNS would make Whonix-Workstation DNS queries non-functional, breaking functionality. This is confirmation of a DNS leak.

Deactivate Qubes DNS[edit]

Platform specific.

  • Non-Qubes-Whonix™: Inapplicable. Use Deactivate host DNS instead.
  • Qubes-Whonix™: See below.

This is similar to Deactivate host DNS. Instead of disabling host DNS, in Qubes terms that would be "disable Qubes dom0 DNS". But since Qubes dom0 is non-networked by default, that is also inapplicable.

For Qubes-Whonix instead, a leak that could include disabling DNS from any or all VMs that are upstream of sys-whonix. By default, sys-whonix is connected to sys-firewall which is connected to sys-net. Therefore to have a test equivalent to Deactivate host DNS, the user could disable DNS in sys-firewall and in sys-net.

Deactivate Whonix-Gateway DNS[edit]

This is already the default. For details, see Whonix-Gateway System DNS.

On the Whonix-Gateway.

Open file /etc/resolv.conf in an editor with root rights.

Non-Qubes-Whonix™

This box uses sudoedit for better security.

sudoedit /etc/resolv.conf

Qubes-Whonix™

NOTES:

  • When using Qubes-Whonix, this needs to be done inside the Template.

sudoedit /etc/resolv.conf

  • After applying this change, shutdown the Template.
  • All App Qubes based on the Template need to be restarted if they were already running.
  • This is a general procedure required for Qubes and unspecific to Qubes-Whonix™.

Others and Alternatives

  • This is just an example. Other tools could achieve the same goal.
  • If this example does not work for you or if you are not using Whonix, please refer to this link.

sudoedit /etc/resolv.conf

comment out everything (# before every line so everything is ignored). 

#nameserver 127.0.0.1

As a test's result the DNS requests in the Whonix-Workstation should still work while the DNS requests in the Whonix-Gateway no longer work.

Using dig[edit]

Another very poor manish leak test: Because Tor's DNS resolver does not handle AAAA records this will not return any google hostnames if run on Whonix-Workstation and DNS requests aren't leaking. Running. 

dig AAAA check.torproject.org

Should reply. 

; <<>> DiG 9.8.1-P1 <<>> AAAA check.torproject.org
;; global options: +cmd
;; Got answer:
;; →>HEADER<<- opcode: QUERY, status: NOTIMP, id: 42383
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;check.torproject.org.          IN      AAAA

;; Query time: 0 msec
;; SERVER: 10.152.152.10#53(10.152.152.10)
;; WHEN: [date]
;; MSG SIZE  rcvd: 38

Tor also does not support DNSSEC yet. Running. 

dig +multiline . DNSKEY

It should now show DNS cryptographic keys. See example output from here.

Using nslookup[edit]

Running. 

nslookup -type=mx check.torproject.org

Should reply. 

Server:         10.152.152.10
Address:        10.152.152.10#53

** server can't find check.torproject.org: NOTIMP

Running 

nslookup -type=AAAA check.torproject.org

Should reply. 

Server:         10.152.152.10
Address:        10.152.152.10#53

** server can't find check.torproject.org: NOTIMP

Leaks through the host or VM[edit]

Shut down the Whonix-Gateway and start the Whonix-Workstation. The Whonix-Workstation shouldn't be able to exchange data with any outside target.

If there's no gateway running, there nobody the workstation can connect to. The workstation internal network endpoint being the gateway simply being unavailable.

Ping Test[edit]

First, make sure both VMs are online. Since ICMP is not supported by Tor and filtered by Whonix firewall, you should not be able to ping any servers.

FIN ACK / RST ACK - Leak Test[edit]

Credit for FIN ACK / RST ACK - Leak Test (coined by Whonix): Originally written by Mike Perry on the tor-talk mailing list, he found a transparent proxy leak without references to Whonix. (sourcearchive.org) The test has been adapted for Whonix.

Note, the following IP 74.125.28.104 points to www.google.com and should be seen as an example.

On the host.

Close your browser and cease all other non-Whonix online activity to avoid contaminating the following test.

Install tcpdump. 

sudo apt update
sudo apt install tcpdump

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

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

For testing/learning, connect to 74.125.28.104 (ping, open in a browser, use curl, scurl or similar) and see how it looks like when a connection to that IP is being made.

Close the connection. Stop tcpdump. Start tcpdump again.

In Whonix-Workstation.

Create a socket connection. 

python

import socket

s = socket.create_connection(("74.125.28.104", 80))

On Whonix-Gateway.

Stop Tor. 

sudo service tor@default stop

In Whonix-Workstation.

Close the socket connection. 

s.close()

On the host.

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

Variations of this test:

Forum discussion:

Integrated tshark leaktest[edit]

On Whonix-Gateway start looking for leaks.

You need to install the anon-gw-leaktest package. 

## Login as user, open a shell as user or su user.
## /usr/bin/leaktest
sudo leaktest

On Whonix-Workstation try to produce a leak.

You need to install the anon-ws-leaktest package. 

## Login as user, open a shell as user or su user.
## /usr/bin/leaktest
sudo leaktest

If you are wondering, how this works and what that does, the old article, Dev/Leak Tests Old is still being kept.

  • Original article.
  • As copy and paste tutorial.
  • For better understanding with more comments.
  • Perhaps useful for similar projects.
  • Optional additional tests.

Integrated systemcheck leaktest[edit]

Please also run systemcheckarchive.org on Whonix-Gateway and Whonix-Workstation. systemcheck's Tor SocksPort and Tor TransPort test (the latter only on Whonix-Workstation [1]) are also doing leak testing. If systemcheck would report a big warning, if check.torproject.org couldn't detect Tor.

systemcheck --leak-tests

Torrent Leak Tests[edit]

UDP Leak Tests[edit]

  • Same as above.
  • Please add more to the list if you know other tests.

Other Leak Tests[edit]

Qubes specific[edit]

Template Update Proxy Leak Test[edit]

Start a your Whonix-Gateway Template (commonly called whonix-gateway-17). [2]

In your TempalteVM.

Start downloading some big[3] package. [4] Example.

apt download firefox-esr

Now switch to your Whonix-Gateway ProxyVM (commonly called sys-whonix) and stop Tor. [5]

sudo service tor@default stop

The expected result in the Template a functional download, that stops as soon as Tor is stopped. 

Get:1 https://deb.debian.org/debian {{Stable project version based on Debian codename}}/updates/main firefox-esr amd64 52.5.2esr-1~deb8u1 [44.7 MB]
Err https://deb.debian.org/debian {{Stable project version based on Debian codename}}/updates/main firefox-esr amd64 52.5.2esr-1~deb8u1
  500  Unable to connect
E: Failed to fetch https://deb.debian.org/debian/pool/updates/main/i/firefox/firefox-esr amd64 52.5.2esr-1~deb8u1_amd64.deb  500  Unable to connect

You can now start Tor in your Whonix-Gateway ProxyVM again.

sudo service tor@default start

Repeat this test with your Whonix-Workstation Template (commonly called whonix-workstation-17).

IP Activity Log Test[edit]

When logged into some services such as for example Twitter, there is an IP log under Twitter /settings/your_twitter_data/login_historyarchive.org.

  1. Find your real external IP address on the host operating system such as by using myip.is or any other website of your choice. Even multiple websites for that purpose.
  2. Compare with twitter activity log.

If real external IP isn't in twitter activity log, then real IP wasn't leaked.

Packet Analyzer[edit]

  • wireshark
  • tshark

Application Specific Leak Tests[edit]

Sorted roughly by difficulty. Easiest on top. More difficult on bottom.

  1. Setup a server. Perhaps for simplicity, a server dedicated for leak testing only. Setup the server software used by the client software intended to leak check. Connect to self-hosted server using the client software intended to be leak checked. Monitor incoming connections to own server. This leak test while interesting might not catch all types of leaks such as DNS leaks.
  2. If source-available: Review the application source code.
  3. If closed source: Avoid Non-Freedom Software or reverse engineering.
  4. Use a Packet Analyzer.

Unsuitable Tests[edit]

Location Detection[edit]

As per Tor upstream (original developer) default setting, Tor keeps changing Tor circuits, specifically if a Tor circuit was broken.

Tor exit relays are hosted by volunteers in many different countries which also keep changing, specifically if a previous Tor circuit was previously unusable by Tor (as simple as a Tor relay restart due to applying operating system updates leading to a Tor circuit being down and user experiencing connection reset).

Location detection can be very inaccurate. Sometimes clearnet IP addresses are being detected several hundred miles away from the actual location. Source: personal experience of Whonix developer Patrick. There are probably many people on search engines confirming the same. Please edit if you know any better sources and/or structured research in this topic.

Operating System Detection[edit]

Operating System Detection tests can be unreliable.

In the personal experience of Whonix developer Patrick, for example Twitter /settings/sessionsarchive.org had shown Windows as operating system used as the only active session while in fact it was a browser running on a Linux based operating system.

While Twitter /settings/sessions is not branded as a browser test it is effectively a browser test. Therefore issues described with these on the Browser Tests wiki page equally apply.

Nyx[edit]

Tor Controller Nyx is also unsuitable, see Whonix Nyx FAQ.

Search Engine Search Results[edit]

Even if Google or anyone else had the possibility to break Tor or Whonix, they would not inform the public about their capability by showing showing more relevant search results.

Others[edit]

are Unsuitable Connectivity Troubleshooting Tools.

See Also[edit]

Footnotes[edit]

  1. ↑ Because Whonix-Gateway does not have a TransPort by default.
  2. ↑ Those are assumed to be torified, i.e. having their NetVM set to sys-whonix.
  3. ↑ With a small package you would not have a chance to easily and quickly disable Tor while it is downloading.
  4. ↑ Alternatively, you could also run sudo apt update instead of downloading a big package and interrupt that. However, it would be less conclusive, because then APT updating may only break due to broken DNS. A long running transfer that no longer depends on functional DNS resolution would be far easier to spot. (If the download was non-torified, it should not matter if we stop Tor during the transfer.)
  5. ↑ Alternately, although with less conclusive, instead of stopping Tor, you could also stop qubes-updates-proxy during the transfer. sudo service qubes-updates-proxy stop This should lead to the same expected result.
Your support makes
all the difference!

We believe security software like Whonix needs to remain open source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!

Retrieved from "https://www.whonix.org/w/index.php?title=Dev/Leak_Tests&oldid=101412"