If you're into C++ or Qt, we could use some help. Mumble[0] is a free software VoIP application that various people have had success using with Tor. One problem using Mumble with Tor is that Mumble doesn't abide by the native proxy settings when looking up Mumble servers[1]. When using a Tor router device or Torsocks, the DNS requests are just dropped. When using the native proxy settings, the DNS requests still get sent out to the local ISP, not through the proxy.
The desired outcome is that if a SOCKS5 proxy is set, DNS requests get sent through the SOCKS5 proxy. The proxy is set as g.s.ptProxyType, and gets set when main.cpp calls NetworkConfig::SetupProxy(), which in turn uses QNetworkProxy::setApplicationProxy.
The window that makes these DNS requests is ConnectDialog.cpp, but you'll want to look at Cert.cpp as well.
I submitted a pull request[2] that allows users to completely turn off automatic UDP and DNS traffic sent out to the big list of public Mumble Servers. This does not stop the automatic DNS traffic that gets sent to servers on the Favorite servers list though, which is where any private servers you might want to connect to would be.
Getting this fixed would be great for Tor because it would make VoIP over Tor easier and safer for people on all platforms. Please help!
[0]: http://mumble.info [1]: https://github.com/mumble-voip/mumble/issues/1033 [2]: https://github.com/mumble-voip/mumble/pull/1128
Matt, have you gotten any response?
On Thu, Jan 30, 2014 at 10:01 PM, Matt matt@pagan.io wrote:
If you're into C++ or Qt, we could use some help. Mumble[0] is a free software VoIP application that various people have had success using with Tor. One problem using Mumble with Tor is that Mumble doesn't abide by the native proxy settings when looking up Mumble servers[1]. When using a Tor router device or Torsocks, the DNS requests are just dropped. When using the native proxy settings, the DNS requests still get sent out to the local ISP, not through the proxy.
The desired outcome is that if a SOCKS5 proxy is set, DNS requests get sent through the SOCKS5 proxy. The proxy is set as g.s.ptProxyType, and gets set when main.cpp calls NetworkConfig::SetupProxy(), which in turn uses QNetworkProxy::setApplicationProxy.
The window that makes these DNS requests is ConnectDialog.cpp, but you'll want to look at Cert.cpp as well.
I submitted a pull request[2] that allows users to completely turn off automatic UDP and DNS traffic sent out to the big list of public Mumble Servers. This does not stop the automatic DNS traffic that gets sent to servers on the Favorite servers list though, which is where any private servers you might want to connect to would be.
Getting this fixed would be great for Tor because it would make VoIP over Tor easier and safer for people on all platforms. Please help!
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Matt matt@pagan.io writes:
If you're into C++ or Qt, we could use some help.
Technically I can claim to know those things, but it's been a while since I've used Qt, and never really their networking stuff.
I took a quick look, though, and it looks to me from Qt's docs that having the ConnectDialog do lookups "itself" is the (at lesat "a") problem. If instead all the QHostAddress objects used hostnames I *think* it would work -- but the dialog is ultimately using them to do pings, anyway (and by default hides everything which hasn't had a successful ping yet). So, that won't work over Tor anyway.
Basically, there doesn't seem to be a Qt API for using SOCKS5 to do "just" DNS lookups -- you can connect a tcp/udp stream using a QHostAddress that is not-yet-looked up, but can't simply ask the proxy for a DNS lookup.
One way to get lookups would be to contact a DNS server oneself via a SOCKS (Tor) connection -- but then you have to do DNS "yourself", which sounds like the wrong answer.
Another way would be to re-work ConnectDialog so that the "pinging" stuff is optional. (And turn off the "ShowReachable" option that hides all non-pingable servers).
For Cert.cpp, it seems to be simply confirming that a lookup succeeds for the certificate's domain provides some answer. Is that strictly necessary? Maybe another option here would be to try to tcp-connect to the certificate's hostname if there's some port that "should" be open...?
-
Andrew F -
Matt -
meejah