BOINC Environment
OS: Linux - Debian 7 (wheezy) 64-bit
BOINC: 7.0.65+dfsg-3~bpo70+1 [Installed from Debian wheezy backports repository]

I am trying to make boinc use my local tor service for all of its internet traffic. When using the SOCKS proxy in the BOINC Manager and pointing it to tor, tor warns me that BOINC may be performing DNS resolutions through my normal internet connection and not passing that traffic through the SOCKS proxy (since Tor is only seeing IPs coming from BOINC over SOCKS).

My question is, when using the BOINC Manager SOCKS proxy, are DNS lookups still sent through it? Or does the BOINC program not use DNS lookups and work strictly on IPs (I figure this is unlikely)?

If BOINC is sending DNS requests and not using the configured SOCKS proxy, I need to attempt to use an application such as torsocks which will take care of that issue. However, in order to do that, when Linux starts the BOINC service on startup, I need to tell the startup script to execute "runwithtor /usr/bin/boinc" instead of the standard /usr/bin/boinc so the torsocks wrapper can sandbox BOINCs connections, including leaked DNS lookups. I made some futile attempts to edit the /etc/init.d/boinc-client script, but I don't believe it to be functioning properly (I changed BOINC_CLIENT=usewithtor /usr/bin/boinc).

Does anyone familiar with tor and BOINC have any info that might answer any of these issues? Specifically, whether running BOINC normally with the SOCKS proxy if DNS lookups are sent out that proxy as well? If so, then I don't need to use tor wrappers to prevent DNS leaks. If not, then I need some info on how to edit the startup procedure for BOINC so it executes using a torsocks or other tor-based wrapper.

I realize this is a very specific and potentially confusing issue, so I hope the above information will adequately explain the situation and how I'm trying to resolve it. Feel free to toss out any questions for additional clarification on specifics I neglected to include.

I asked the developers, perhaps that one of them knew the answer. Thus far not yet. But here's a clue for you: BOINC passes URLs to the Curl library, which handles all name resolution and network communication.

---

Thank you for asking the question. I'm sorry to hear none had a definitive answer. Knowing that it's passing the information to Curl helps. It would seem BOINC does leak DNS resolution information while using its SOCKS proxy, as Curl is passing only an IP address to Tor. BOINC also does not appear to tell the user what SOCKS protocol is specifically being used (SOCKS4, SOCKS4a, or SOCKS5), the latter two protocols having support for name resolution, whether it's being implemented or not.

If the SOCKS proxy method being used is leaking DNS information, I think this is something that should be looked into or at least considered by the development team to change, since anyone using the proxy for privacy reasons are vulnerable to traffic analysis and other remote traffic correlation attacks.

I run the BOINC client 24/7 on several computers in my LAN and I would prefer all of their traffic go out through Tor via BOINC's SOCKS proxy with remote DNS (such as a proper implementation of SOCKS 4a). Allowing the DNS info to slip out through my physical WAN IP while having the IP traffic going through Tor would allow a remote attacker to correlate the physical address of my Tor node with a high statistical probability. This would have the unfortunate side effect of my having to discontinue use of the BOINC client or having to take more elaborate measures to properly insulate BOINC's network traffic.

I will do some packet sniffing on my machine just to 100% confirm the DNS is being leaked by BOINC and will post back here with the results of that information, just so people are aware and can hopefully take appropriate measures to ensure their privacy.

I realize this may seem a bit tinfoil hat-ish, but knowing more about the NSA and US spy programs and their apparent world-wide usage, being able to maintain a certain level of privacy is becoming absolutely essential. Application leaks such as this are of serious concern, since they essentially undermine the foundation of application-layer network security I have setup beneath them.

The following is a tcpdump that I filtered to capture DNS requests while running BOINC in SOCKS mode and running a BOINC Update command. Through reviewing my logs, it appears the BOINC client is implementing the SOCKS5 protocol for its proxy, but not routing DNS requests through that proxy:

23:11:15.530685 IP 192.168.1.19.49381 > 192.168.1.1.53: 48863+ A? www.malariacontrol.net. (40)
23:11:15.588766 IP 192.168.1.1.53 > 192.168.1.19.49381: 48863 2/4/8 CNAME africa-home1.unige.ch., A 192.33.217.12 (347)
23:11:15.588876 IP 192.168.1.19.42149 > 192.168.1.1.53: 45740+ AAAA? www.malariacontrol.net. (40)
23:11:15.649531 IP 192.168.1.1.53 > 192.168.1.19.42149: 45740 1/1/0 CNAME africa-home1.unige.ch. (127)

The above clearly shows my PC, 192.168.1.19, sending a DNS request for an A-record (and IPv6 AAAA-record) for www.malariacontrol.net to my router, 192.168.1.1 on port 53 (used for DNS) and my router replying back with an answer of 192.33.217.12 for the hostname.

This should be clear evidence that BOINC DNS requests are not being routed through the configured BOINC proxy. Had the requests been sent over the proxy, they would not have appeared in my tcpdump, as it was only listening on my local eth0 interface and the proxy configured in BOINC is my localhost, 127.0.0.1.

If a remote attacker was sniffing traffic between my WAN connection and my DNS servers, they would be aware of my participation in the malariacontrol.net project and running BOINC. That same attacker could be sniffing traffic between my Tor exit and the malariacontrol.net project (or compel direct cooperation from malariacontrol.net) to statistically identify that specific Tor traffic is coming from my computer, which could be used to further statistically correlate non-BOINC traffic going over Tor as having originated from my connection, using end-to-end correlation: something that is not exceptionally difficult for a government agency or an individual with a botnet of compromised computers and knowledge of programming and statistics, as described by Microsoft Researcher George Danezis in a 2004 paper; the specifics pertaining to my example are contained within Section 3 of the paper.

Regarding Curl's Involvement & Implementation in BOINC

Some quick research into Curl and libcurl3 (and their Debian 7 binary implementations) tells me that curl supports SOCKS5 hostname resolution, using one of the following two methods (from the curl manpage):

--socks5-hostname <host[:port]>

Use the specified SOCKS5 proxy (and let the proxy resolve the host name). If the port number is not specified, it is assumed at port 1080. (Added in 7.18.0)

Since 7.21.7, this option is superfluous since you can specify a socks5 hostname proxy with -x, --proxy using a socks5h:// protocol prefix.

-x, --proxy <[protocol://][user:password@]proxyhost[:port]>

From 7.21.7, the proxy string may be specified with a protocol:// prefix to specify alternative proxy protocols. Use socks4://, socks4a://, socks5:// or socks5h:// to request the specific SOCKS version to be used. No protocol specified, http:// and all others will be treated as HTTP proxies.

I can confirm that the implementation of Curl in Debian 7 Wheezy has support built-in for both --socks5-hostname and using socks5h:// with the -x option, so the issue is not that Curl doesn't support what I'm proposing, it just appears that the option is not taken advantage of by the BOINC software. Implementing it seems relatively simplistic (adding an option [--socks5-hostname] with the curl request or changing the curl URL prefix to socks5h:// when SOCKS is enabled), however I'm not a developer.

I did forward all your posts to the developers. Nothing back yet.

---

Tor? Played with it in past and had BOINC issues and now, well it made the news: http://www.bbc.co.uk/news/technology-23984814

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt