Version: 0.11.1 (using KDE Devel) Installed from: Compiled sources Compiler: GCC 4.0.2 (thread model: posix, host: i686-pc-linux-gnu) OS: Linux Hello, I've chose Tor (http://tor.eff.org) as the gateway to some of my Internet uses : Web-browsing & IM. so I did install Dante (a Socks-client), Configured Dante, and then configured KDE to use Dante as a Socks-client. This Configuration works well (tested using Konqueror & Kopete). Anyway, The issue was discovered when I wanted Tor to also resolve the DNS queries on my behalf - for better privacy. Tor, has a feature (and a matching config-setting) that logs whatever if It got a target IP-address (bad for privacy) - or a Hostname (good for privacy), this Tor config-setting is named "TestSocks". After enabling this feature in Tor, I found that Kopete, in contrary to Konqueror and Mozilla-Firefox, gives the Socks Proxy an IP-address (bad for privacy) - instead of an Hostname (good for privacy). I did my Kopete testing while connecting to the ICQ & MSN Networks. When a program (like : Kopete-0.11.1) gives the Tor Socks-Proxy a an IP-address instead of a Hostname, the log-message looks like this : --- Mar 01 17:00:52.364 [warn] fetch_from_buf_socks(): Your application (using socks5 on port 5190) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider using Socks4A (e.g. via privoxy or socat) instead. For more information, please see http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#SOCKSAndDNS" --- and When a program (like : Konqueror-3.5.1 and Mozilla-Firefox-1.5) gives the Tor Socks-Proxy a Hostname instead of an IP-address, the log-message looks like this : --- Mar 01 17:07:55.474 [notice] fetch_from_buf_socks(): Your application (using socks4a on port 80) gave Tor a hostname, which means Tor will do the DNS resolve for you. This is good. --- This issue might put some of the ones who need protection from their "big brother" (in non-democratic countries, in corrupted corporations & etc.), at great danger. If there's anything I can do to assist on solving this issue, Please do contact me, and I'll do what I can. Thankyou, for your greatly estimated work on Kopete :) Moran Z.
IMO, this is invalid for ICQ since we don't get a hostname back from the server for the second connection (ICQ login involves two seperate connections) and the network classes are perfectly happy with the IP address it gets from the server. There is no point to make several more roundtrips just to look up the hostname. I can't comment on MSN.
I can say (after an examination of the Tor Socks-proxy log-files) that no matter how many queries Kopete did send to the ICQ server(s), the Tor Socks-Proxy only had been given an IP-address - and not a Hostname.
* an IP-Address = only IP-Addresses * a Hostname = a single Hostname
I don't know how the underlying network classes work in terms of name resolution before connection, but it would seem to me that the difference between Konqueror and Kopete is the use of ioslaves by Konqueror. Since ioslaves work differently from Kopete's connections this could explain the difference. Thiago: can you provide some more information please? Thanks. :)
The only way to use SOCKS to do DNS queries, at the moment, is to use "socksify" or a similar LD_PRELOAD-trick.
BTW, Kopete is behaving as expected: it's NOT using SOCKS to send DNS queries. That's how the whole of KDE behaves, except for kio_http.
I did try "socksify" (Dante) and also "torify" (tsocks), and found that neither of them catches the "gethostbyname" syscall(s). Why doesn't KDE at general use the configured SOCKS Proxy to do the name resolution (DNS) ? Anyhow and IMHO, It probably would be better if the user could choose whatever if to use the SOCKS Proxy for doing DNS or not.
There are two reasons for that: * the first is that the code to do that has never been written * the second is that, in order to comply with the list of exceptions that are listed as IP addresses, we have to resolve the IP address. And I'd rather not send a DNS request over SOCKS, but tell SOCKS to connect to the hostname. It's a bit of chicken-and-the-egg problem...
I indeed wrote something like "... use the SOCKS Proxy to do the name resolution (DNS)" - but actually meant that the SOCKS Proxy should be supplied with a Hostname instead of an IP-Address. sorry for being a bit unclear. And as said before, IMHO, the User should better be let decide whatever if to supply the SOCKS Proxy with Hostnames or IP-Addresses - maybe by a simple Checkbox at the KDE Proxy Configuration menu ?
No. This is too low-level for configuration. When I implement this, ALL proxy requests will use hostname or NONE. It all depends on how I implement this. People are free to disagree, of course, as long as they supply patches that change the behaviour.
Sounds promising, as longs as Hostnames will be used instead of IP-Addresses :)
they won't always be used. Comment #1 explains why.
So there is nothing we can do, sorry. As Matt explained in Comment #1 this is not possible with oscar. Same goes for MSN, we resolve messenger.msn.com the first time, and after, the MSN server reply us with the IP we need to connect to for the NS session or the chat session. It should anyway works with Jabber, since it require only one connection with the server which is done by dns resolving. (it will fail to verify SSL certificate, but this may be contourned)
I still can't see why won't every part of KDE, where apply, give the KDE Configured Socks-Proxy the Hostname or IP_address - AS IS - instead of doing the name-resolution on their own. I seem not to be able to deliver my message here - over and over again, why is that ? am I not clear enough ? should I add any further explanation of and/or info on my idea ?
* the Hostname or IP_address = the Hostname or IP_address that the aforementioned part of KDE has
and assign to the newly created component
Hi, kdelibs (version 4 and earlier) is no longer maintained since a few years. KDE Frameworks 5 or 6 might already have implemented this wish. If not, please re-open against the matching framework if feasible or against the application that shows the issue. We then can still dispatch it to the right Bugzilla product or component. Greetings Christoph Cullmann