On Fri, 07 Feb 2014 09:54:35 +0400 meejah meejah@meejah.ca wrote:
What I would suggest:
- change ConnectDialog so that it always uses not-yet-looked-up QHostAddresses (perhaps only if a proxy is enabled). This still
won't help Tor, since they're sending UDP.
- change Cert.cpp so it doesn't have to do a host-lookup. I sort-of asked in my other email, but does this actually gain anything?
That is, does checking that the domain looks up "to something" really accomplish anything useful? If the answer is "yes", then more thinking; all I can think of is attempting a TCP/UDP connection (again, with a not-yet-looked-up QHostAddress) to the server in question (which will only work if there is a well-known port upon which it should be listening to be considered valid).
I haven't actually confirmed that there is a DNS leak here. I've been focusing mostly on ConnectDialog, but mentioned Cert because it also had DNS-related code that I hadn't spent as much time with.
- suggest/document that Tor uses need to un-set the "show reachable" (Settings::ShowReachable) option so that a server doesn't need a valid ping-reply to show up in the list.
Another option might be to factor out all the "ping" stuff to its own class and simply not instatiate/use it when ShowReachable is off (or have a separate option for pinging all the servers).
Yet another different option might be to just have an option to turn off the pinging of servers, leaving open the Cert.cpp question (which one could also punt on by having an option). Then the game would be to get Tor users to have the right options enabled ;)
I tried to do something like this in my branch; optionally turning off pings to Public and LAN servers was easy. Turning off pings to Favorite servers seemed a little trickier, especially if they are still to remain reachable.
Thanks for all the pointers. A C++ developer volunteered to take a closer look at this issue. At this point, I think further discussion would most useful for all parties if it moved onto the bug ticket: https://github.com/mumble-voip/mumble/issues/1033
Any movement on this? anything new?
On Sun, Feb 9, 2014 at 9:52 PM, Matt matt@pagan.io wrote:
On Fri, 07 Feb 2014 09:54:35 +0400 meejah meejah@meejah.ca wrote:
What I would suggest:
- change ConnectDialog so that it always uses not-yet-looked-up QHostAddresses (perhaps only if a proxy is enabled). This still
won't help Tor, since they're sending UDP.
- change Cert.cpp so it doesn't have to do a host-lookup. I sort-of asked in my other email, but does this actually gain anything?
That is, does checking that the domain looks up "to something" really accomplish anything useful? If the answer is "yes", then more thinking; all I can think of is attempting a TCP/UDP connection (again, with a not-yet-looked-up QHostAddress) to the server in question (which will only work if there is a well-known port upon which it should be listening to be considered valid).
I haven't actually confirmed that there is a DNS leak here. I've been focusing mostly on ConnectDialog, but mentioned Cert because it also had DNS-related code that I hadn't spent as much time with.
- suggest/document that Tor uses need to un-set the "show reachable" (Settings::ShowReachable) option so that a server doesn't need a valid ping-reply to show up in the list.
Another option might be to factor out all the "ping" stuff to its own class and simply not instatiate/use it when ShowReachable is off (or have a separate option for pinging all the servers).
Yet another different option might be to just have an option to turn off the pinging of servers, leaving open the Cert.cpp question (which one could also punt on by having an option). Then the game would be to get Tor users to have the right options enabled ;)
I tried to do something like this in my branch; optionally turning off pings to Public and LAN servers was easy. Turning off pings to Favorite servers seemed a little trickier, especially if they are still to remain reachable.
Thanks for all the pointers. A C++ developer volunteered to take a closer look at this issue. At this point, I think further discussion would most useful for all parties if it moved onto the bug ticket: https://github.com/mumble-voip/mumble/issues/1033 _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
Andrew F -
Matt