tor/privacy (socks5) option giving ssl error
Hello, Pidgin 2.10.6 (libpurple 2.10.6) 4cfe697ea3ae39a4fb3dad8e3ed1c70855901095 I am trying to connect to Tor using Pidgin. I am having a connection issue. Of the three proxy options socks4, socks5, and tor/privacy(socks5), it seems I should be using tor/privacy(socks5). This issue has come up on some Tor lists. Can someone explain exactly what is the difference between Tor/Privacy Socks5, and just Socks5, and whether you believe Pidgin to preserve the anonymity? And also, my question as to why on my system, socks 5 works, but Tor/Privacy(Socks5) results in SSL connection error almost immediately (i.e. I don't think it is even making any network activity, it just immediately displays the SSL connect error. Setting Socks5 works fine. Thanks ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: tor/privacy (socks5) option giving ssl error
On Tue, Apr 2, 2013 at 7:08 PM, Ileana ile...@fairieunderground.info wrote: Hello, Pidgin 2.10.6 (libpurple 2.10.6) 4cfe697ea3ae39a4fb3dad8e3ed1c70855901095 I am trying to connect to Tor using Pidgin. I am having a connection issue. Of the three proxy options socks4, socks5, and tor/privacy(socks5), it seems I should be using tor/privacy(socks5). This issue has come up on some Tor lists. Can someone explain exactly what is the difference between Tor/Privacy Socks5, and just Socks5, and whether you believe Pidgin to preserve the anonymity? The difference is that the Tor/Privacy proxy will disable various other pieces of functionality (e.g. DNS queries) instead of just proxying actual connections through a proxy. If you have pidgin configured appropriately (e.g. disabling UPnP, etc) we're not aware of any leakage of information to someone listening between you and the proxy endpoint. And also, my question as to why on my system, socks 5 works, but Tor/Privacy(Socks5) results in SSL connection error almost immediately (i.e. I don't think it is even making any network activity, it just immediately displays the SSL connect error. Setting Socks5 works fine. You didn't provide any context to the specific issue, but the likely reason for this particular error is that the Tor/Privacy Socks5 mode will prevent DNS queries from occurring and this probably has the effect of preventing you from determining the correct server to connect to (e.g. a DNS SRV lookup is necessary to connect to the appropriate XMPP server for a number of domains unless you specify a Connect Server manually). -D ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: tor/privacy (socks5) option giving ssl error
You didn't provide any context to the specific issue, but the likely reason for this particular error is that the Tor/Privacy Socks5 mode will prevent DNS queries from occurring and this probably has the effect of preventing you from determining the correct server to connect to (e.g. a DNS SRV lookup is necessary to connect to the appropriate XMPP server for a number of domains unless you specify a Connect Server manually). Daniel, Sorry for the lack of context. I am using tor and pidgin Pidgin 2.10.6 (libpurple 2.10.6), on linux. I am connecting to a normal irc server. It works with socks 5, it doesn't work, and immediately fails, with tor/privacy socks5 with error ssl connection failed. When I try to connect to an IRC tor hidden service address (blahblahblah.onion) I get: Unable to connect: Aborting DNS lookup in Tor Proxy mode. When I try to connect to a regular IRC address/hostname, I get SSL Connection Failed. Both work when I select socks5. Neither works with tor/privacy(socks5). Are you suggesting I should be putting the ip addresses in directly for these hostnames? That isn't even possible in the case of the hidden service addresses. And the hidden service address seems to resolve and work fine with the socks5 setting. I don't see how this can't be some kind of bug? Aren't the dns requests supposed to go through the proxy? Do you need to add a check box (do dns lookup at proxy end), as appears in the main proxy config screen, for each individual setting? I am concerned some users may be using pidgin incorrectly. But you might be right that it is a dns problem, and it is attempting the lookup locally. In the case of the TAILS OS, all dns is transparently routed over the tor, so local dns gets resolved, and that would work. But for most privacy users, local dns queeries are a big no-no, yet they need to be done, and hence are done via socks 5 at proxy end. What is the workaround now? Use socks4 and make the changes? Is it sufficient to turn off unpp and disable uneccessary plugins, or is the tor/privacy setting doing stuff in the code that an end user can't set manually? I.E. If I just use socks5 and disable plugins, is that enough? Does it do anything versus cctp/ping/dcc etc? Thanks ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: tor/privacy (socks5) option giving ssl error
From my basic understanding, a tor/privacy setting should ensure: *no local dns lookups (perhaps as an options checkbox) socks4 automatically does lookup at end...there is no option. socks5 you have option for local or remote dns in the spec. Most tor users want remote, except in the case of TAILS a user might handle the dns queeries locally(and then resolving them through for instance tor's dns port). I think the same side is to do them remotely. *real ip address never gets sent out *no other system information gets sent out(kernel version, uname, os, etc) *nothing that seems to be a unique identifier gets sent out upon connect/reconnect. (i.e. ssl session ids, user agents/version, etc). *timestamps all converted to utc *any functionality such as dcc where there is a direct connection to the other client should either be disabled or also insure real ip is not leaked. I can't think of anything else off the top of my head, but I may have missed something. If you are a developer and can point me to a link to the code that handles the proxy settings, I would take a further look. Thanks ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: tor/privacy (socks5) option giving ssl error
On Tue, Apr 2, 2013 at 8:55 PM, Ileana ile...@fairieunderground.info wrote: You didn't provide any context to the specific issue, but the likely reason for this particular error is that the Tor/Privacy Socks5 mode will prevent DNS queries from occurring and this probably has the effect of preventing you from determining the correct server to connect to (e.g. a DNS SRV lookup is necessary to connect to the appropriate XMPP server for a number of domains unless you specify a Connect Server manually). Daniel, Sorry for the lack of context. I am using tor and pidgin Pidgin 2.10.6 (libpurple 2.10.6), on linux. I am connecting to a normal irc server. It works with socks 5, it doesn't work, and immediately fails, with tor/privacy socks5 with error ssl connection failed. When I try to connect to an IRC tor hidden service address (blahblahblah.onion) I get: Unable to connect: Aborting DNS lookup in Tor Proxy mode. When I try to connect to a regular IRC address/hostname, I get SSL Connection Failed. You'll need to provide more details - a sanitized debug log (Help-Debug Window) from when it tries to connect should help. Both work when I select socks5. Neither works with tor/privacy(socks5). Are you suggesting I should be putting the ip addresses in directly for these hostnames? That isn't even possible in the case of the hidden service addresses. And the hidden service address seems to resolve and work fine with the socks5 setting. No, that's not necessarily what I'm suggesting. I don't see how this can't be some kind of bug? Aren't the dns requests supposed to go through the proxy? Do you need to add a check box (do dns lookup at proxy end), as appears in the main proxy config screen, for each individual setting? Again, it's hard to say without more information. It's not possible to do all DNS requests through the proxy - you can pass a hostname to the proxy and have it resolve it, but e.g. a SRV request can't be done through a proxy. No, that checkbox is globally applied, it doesn't need to be more granularly applied. I am concerned some users may be using pidgin incorrectly. But you might be right that it is a dns problem, and it is attempting the lookup locally. In the case of the TAILS OS, all dns is transparently routed over the tor, so local dns gets resolved, and that would work. But for most privacy users, local dns queeries are a big no-no, yet they need to be done, and hence are done via socks 5 at proxy end. What is the workaround now? Use socks4 and make the changes? Is it sufficient to turn off unpp and disable uneccessary plugins, or is the tor/privacy setting doing stuff in the code that an end user can't set manually? I.E. If I just use socks5 and disable plugins, is that enough? Does it do anything versus cctp/ping/dcc etc? TAILS is pretty much irrelevant from the application perspective. I'm going to hold off answering the rest because we don't know what the problem is. -D ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: tor/privacy (socks5) option giving ssl error
On Tue, Apr 2, 2013 at 9:11 PM, Ileana ile...@fairieunderground.info wrote: From my basic understanding, a tor/privacy setting should ensure: All of my answers below apply to stock Pidgin when you select Tor/Privacy in the proxy settings- any third party plugins could change the behavior. Some effort has been put into making XMPP safe from a privacy perspective; other protocols have issues - good patches are always welcome. *no local dns lookups (perhaps as an options checkbox) socks4 automatically does lookup at end...there is no option. socks5 you have option for local or remote dns in the spec. Most tor users want remote, except in the case of TAILS a user might handle the dns queeries locally(and then resolving them through for instance tor's dns port). I think the same side is to do them remotely. The libpurple DNS functionality will be blocked - anything that can be done through the proxy will be done, otherwise the functionality will fail (for things using the libpurple DNS API). It's possible that protocols like gadu-gadu or sametime, which use external libraries to implement the protoco,l would make DNS requests without using the libpurple API. It looks like Bonjour/Link-Local accounts will send stuff out on your local network, because that's how the protocol works. *real ip address never gets sent out This should be the case for XMPP. If libpurple/Pidgin is configured appropriately, it won't know what your external IP address is. *no other system information gets sent out(kernel version, uname, os, etc) Your IRC account default settings contain some information from your OS user account, but you're free to change them. See https://developer.pidgin.im/ticket/15295 There may be other issues for other protocols *nothing that seems to be a unique identifier gets sent out upon connect/reconnect. (i.e. ssl session ids, user agents/version, etc). Of course unique things will be sent out - you're connecting to a IM account and your account name will be sent out (and possibly your password too depending on what you're connecting to). *timestamps all converted to utc I'm not sure if there are places where your timezone or information that can be used to deduce your timezone are sent out, but I don't consider this sensitive. *any functionality such as dcc where there is a direct connection to the other client should either be disabled or also insure real ip is not leaked. This wouldn't be a reasonable assumption to make for protocols other than XMPP. I can't think of anything else off the top of my head, but I may have missed something. If you are a developer and can point me to a link to the code that handles the proxy settings, I would take a further look. libpurple/proxy.c ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: tor/privacy (socks5) option giving ssl error
On Tue, 2 Apr 2013 21:46:20 -0400 Daniel Atallah datal...@pidgin.im wrote: Daniel, Sorry for the lack of context. I am using tor and pidgin Pidgin 2.10.6 (libpurple 2.10.6), on linux. I am connecting to a normal irc server. It works with socks 5, it doesn't work, and immediately fails, with tor/privacy socks5 with error ssl connection failed. When I try to connect to an IRC tor hidden service address (blahblahblah.onion) I get: Unable to connect: Aborting DNS lookup in Tor Proxy mode. When I try to connect to a regular IRC address/hostname, I get SSL Connection Failed. You'll need to provide more details - a sanitized debug log (Help-Debug Window) from when it tries to connect should help. (21:49:24) account: Connecting to account foo44...@irc.oftc.net. (21:49:24) connection: Connecting. gc = 0xb83c3868 (21:49:24) dnsquery: Performing DNS lookup for localhost (21:49:24) dnsquery: Aborting DNS lookup in Tor Proxy mode. (21:49:24) proxy: Connection attempt failed: Aborting DNS lookup in Tor Proxy mode. (21:49:24) connection: Connection error on 0xb83c3868 (reason: 0 description: SSL Connection Failed) (21:49:24) account: Disconnecting account foo44...@irc.oftc.net (0xb7c39428) (21:49:24) connection: Disconnecting connection 0xb83c3868 (21:49:24) connection: Destroying connection 0xb83c3868 (21:49:28) autorecon: do_signon called (21:49:28) autorecon: calling purple_account_connect I don't understand this...it says it is doing dns lookup for localhost? Ahh! I found it...I had localhost in the settings rather then 127.0.0.1. When I set it to 127.0.0.1 for the proxy host, it works. I see, it cuts off all local dns requests, including looking at the host file. I am not sure if this should be documented...most other applications (firefox, thunderbird, etc) have the option to do some names locally, in particular, localhost should usually work. This may be considered a minor bug? Again, it's hard to say without more information. It's not possible to do all DNS requests through the proxy - you can pass a hostname to the proxy and have it resolve it, but e.g. a SRV request can't be done through a proxy. No, that checkbox is globally applied, it doesn't need to be more granularly applied. Perhaps you are right. And I am mixed up in my statements. socks 4 you have the option local/remote dns. socks4a seems to automatically do remote, no option, but pidgin doesn't seem to do socks4a. And socks5 again the option, but it seems the common setting is to do remote lookup. I am concerned some users may be using pidgin incorrectly. But you might be right that it is a dns problem, and it is attempting the lookup locally. In the case of the TAILS OS, all dns is transparently routed over the tor, so local dns gets resolved, and that would work. But for most privacy users, local dns queeries are a big no-no, yet they need to be done, and hence are done via socks 5 at proxy end. What is the workaround now? Use socks4 and make the changes? Is it sufficient to turn off unpp and disable uneccessary plugins, or is the tor/privacy setting doing stuff in the code that an end user can't set manually? I.E. If I just use socks5 and disable plugins, is that enough? Does it do anything versus cctp/ping/dcc etc? TAILS is pretty much irrelevant from the application perspective. I'm going to hold off answering the rest because we don't know what the problem is. OK...I see what you are saying. I see how TAILS should be irrelevant from the application end...up into the point the application itself is sending out information that could deanoymize the client. TAILS really can't do anything about that, hence I like that pidgin is compartmentalizing the problem by having this privacy setting. I just think it should be documented exactly what it is doing. It seems your Tor/Privacy mode should keep the user, by any means possible, from doing un-intentional loss of private information at the application level. Thanks for helping me resolve this, and your obvious work on this app, which is really nice. I guess I will have to look at the code to see exactly what is the difference from the socks5/torprivacy setting? You mentioned, obviously, it blocking DNS, and we see that here. I am wanting a full list of differences. ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: tor/privacy (socks5) option giving ssl error
On Tue, 2 Apr 2013 22:36:51 -0400 Daniel Atallah datal...@pidgin.im wrote: On Tue, Apr 2, 2013 at 9:11 PM, Ileana ile...@fairieunderground.info wrote: From my basic understanding, a tor/privacy setting should ensure: All of my answers below apply to stock Pidgin when you select Tor/Privacy in the proxy settings- any third party plugins could change the behavior. Some effort has been put into making XMPP safe from a privacy perspective; other protocols have issues - good patches are always welcome. Well thanks for the effort. *no local dns lookups (perhaps as an options checkbox) socks4 automatically does lookup at end...there is no option. socks5 you have option for local or remote dns in the spec. Most tor users want remote, except in the case of TAILS a user might handle the dns queeries locally(and then resolving them through for instance tor's dns port). I think the same side is to do them remotely. The libpurple DNS functionality will be blocked - anything that can be done through the proxy will be done, otherwise the functionality will fail (for things using the libpurple DNS API). It's possible that protocols like gadu-gadu or sametime, which use external libraries to implement the protoco,l would make DNS requests without using the libpurple API. It looks like Bonjour/Link-Local accounts will send stuff out on your local network, because that's how the protocol works. *real ip address never gets sent out This should be the case for XMPP. If libpurple/Pidgin is configured appropriately, it won't know what your external IP address is. *no other system information gets sent out(kernel version, uname, os, etc) Your IRC account default settings contain some information from your OS user account, but you're free to change them. See https://developer.pidgin.im/ticket/15295 There may be other issues for other protocols *nothing that seems to be a unique identifier gets sent out upon connect/reconnect. (i.e. ssl session ids, user agents/version, etc). Of course unique things will be sent out - you're connecting to a IM account and your account name will be sent out (and possibly your password too depending on what you're connecting to). Everyone disagrees about the User Agent issue and this has been a big pain in the butt across applications from browsers to torrent to chat. It seems XMPP/Pidgin does send out the timezone and pidgin version/libpurple version. Seems like minor non-senstive stuff but it does allow partitioning of the userspace. *timestamps all converted to utc I'm not sure if there are places where your timezone or information that can be used to deduce your timezone are sent out, but I don't consider this sensitive. *any functionality such as dcc where there is a direct connection to the other client should either be disabled or also insure real ip is not leaked. This wouldn't be a reasonable assumption to make for protocols other than XMPP. I can't think of anything else off the top of my head, but I may have missed something. If you are a developer and can point me to a link to the code that handles the proxy settings, I would take a further look. libpurple/proxy.c Thanks for the info. I will take a look at it. ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
