Re: pidgin autoconnecting--how to disable
However, I think other users also might expect to be able to put localhost in the tor/privacy proxy settings, and may also have no clue why its not working. Not sure if that is enhancement or bug, but it was annoying for me. I can't think of any reason a user would want dns for localhost to be proxied... The string needs to somehow be converted to an IP address. I'm not sure how appropriate it would be to put a special case in for localhost, that'd only be a partial solution and seems like an ugly hack. I'd be interested to know what other applications have done for this issue. Mozilla products have a screen which allows setting either socks4 or socks5 proxy. Whether to do remote dns is, unfortunately, a hidden hard-to-find config option. It should appear on that screen as a checkbox. There is a textbox, No proxy for: in which you list hostnames or ip addresses that will not be proxied, dns or otherwise. The default entry in this text box is localhost, 127.0.0.1. This is particularly useful if you want to connect to some server on the local area network, while still using the proxy for all other connecctions. This I think covers every use case scenario. Ideally, I think you would have the same menu in the global as well as per/account settings, making slightly but not much more complicated then mozilla, which just has the one pref screen per app. The only instance I see of one wanting to proxy localhost or 127.0.0.1 would be if a server admin is connecting to his IRC (for instance) via a ssh dynamic socks5 proxy. he can ssh into the box, and specify localhost for the irc server hostname, this would be sent over proxy, and he would connect locally to the loopback adapter on the server. I think that I would recommend a similar approach. We might not be thinking of every usecase, so might as well do this approach which covers every scenario a user might want to do. This setting should still be available for the tor/privacy proxy as well. ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
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
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, 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
pidgin autoconnecting--how to disable
One other related issue to annonymity/privacy is I don't like how when I start pidgin it starts to autoconnect to all my servers. Is there somewhere I can disable this functionality, so that everytime I start pidgin, it just comes up with the menu for which accounts I want to enable, without the autoconnect. In particular, for anon irc/xmpp, I want to change the usernames before it starts connecting. I know the TAILS team made some modification to turn this off, but I would consider an actual button in the main menu an enhancement request that I think even non-privacy minded people would like this simple feature added. What is the workaround to disable autoconnect? Thanks. ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: pidgin autoconnecting--how to disable
On Tue, 2 Apr 2013 22:18:09 -0500 Ileana ile...@fairieunderground.info wrote: I know the TAILS team made some modification to turn this off, but I would consider an actual button in the main menu an enhancement I correct myself. I would suggest a button in each account menu, Auto-connect when Pidgin starts up? If it is not selected, Pidgin passes over the account, and makes no network activity related to the account. request that I think even non-privacy minded people would like this simple feature added. What is the workaround to disable autoconnect? ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: pidgin autoconnecting--how to disable
On Tue, 2 Apr 2013 23:29:31 -0400 Daniel Atallah datal...@pidgin.im wrote: I correct myself. I would suggest a button in each account menu, Auto-connect when Pidgin starts up? If it is not selected, Pidgin passes over the account, and makes no network activity related to the account. request that I think even non-privacy minded people would like this simple feature added. What is the workaround to disable autoconnect? You can choose a Startup Status in the preferences - if you set that to Offline, it won't connect on startup. There is also the -n argument that you can pass to the pidgin command to disable autologin for that instance. Ha! Thanks. Both of these issues I was dealing with/annoyed for some time, and they were already there. However, I think other users also might expect to be able to put localhost in the tor/privacy proxy settings, and may also have no clue why its not working. Not sure if that is enhancement or bug, but it was annoying for me. I can't think of any reason a user would want dns for localhost to be proxied... Thanks! ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
