Audit jabber/XMPP support for pidgin
Pidgin leaks DNS requests when using the XMPP protocol.
When Pidgin connects to an XMPP server, it makes a DNS request using the system's resolver.
This is also our general ticket for auditing Jabber/XMPP support in Pidgin - if we find that it's safe, we'll be ready to enable it in TIMBB again.
Trac:
Username: katmagic
Activity
Here's the bug report that I filed with Pidgin: http://developer.pidgin.im/ticket/11110
If the Pidgin developers don't fix this -- and it looks to me like they either don't care or don't understand that leaking DNS requests when a proxy is specified is a security hole -- then we have several options:
- write a patch for Pidgin ourselves, and patch Pidgin in TIMBB and/or shove the patch upstream
- stop shipping Pidgin's XMPP plugin in TIMBB
- replace Pidgin in TIMBB with less broken IM/IRC clients
- stop shipping TIMBB and explain why on the blog
Trac:
Owner: helix to erinnReplying to rransom:
If the Pidgin developers don't fix this -- and it looks to me like they either don't care or don't understand that leaking DNS requests when a proxy is specified is a security hole -- then we have several options:
- write a patch for Pidgin ourselves, and patch Pidgin in TIMBB and/or shove the patch upstream
- stop shipping Pidgin's XMPP plugin in TIMBB
- replace Pidgin in TIMBB with less broken IM/IRC clients
- stop shipping TIMBB and explain why on the blog
I vote for #4 (closed).
#4 (closed) sounds good to me, though I sincerely hope it is merely suspended rather than canceled while we sort out one of the other solutions. We definitely should not continue to ship something that endangers our users.
We should make sure to direct the angry hordes to the Pidgin bug too. :) By "we" I mean "me", when I write the blog post.
Trac:
Actualpoints: N/A to N/A
Cc: N/A to amnesia@boum.org
Points: N/A to N/AReplying to T(A)ILS developers:
There has been some activity on the upstream bug recently: a long-time Pidgin contributor reopened the bug and stated s/he intended to look at it and "bang out some kind of temporary fix".
It's not fixed yet. We should stop shipping Pidgin's XMPP plugin, if not Pidgin or TIMBB, until this bug is actually fixed (and the fix is reviewed by someone we trust).
#1325 (closed) is also relevant to a discussion of whether or not to continue shipping Pidgin and/or TIMBB.
There have been no further updates to the Pidgin bug since comment 16, currently 8 weeks ago. Do we fix Pidgin, toss Pidgin's XMPP plugin, or toss Pidgin?
Trac:
Priority: normal to criticalI think it is the wrong approach to kneecap our users by pulling TIMBB without public notice. I am going to work on fixing this in Pidgin on Linux if I can repro the bug with a current copy of Pidgin (pidgin-2.7.11) - I guess my patch will fix it for our users but I doubt it will be accepted upstream.
I am building this on Linux with the following configure arguments:
./configure --disable-screensaver --disable-gstreamer --disable-vv --disable-idn --disable-meanwhile --disable-dbus --disable-perl --disable-tcl --enable-gnutls=no --enable-nss=yes --disable-consoleui time makeThis produces a Pidgin and I will use this as the basis for my work.
I've also built pidgin-otr plugin to be included: http://www.cypherpunks.ca/otr/pidgin-otr-3.2.0.tar.gz
Replying to katmagic:
When Pidgin connects to an XMPP server, it makes a DNS request using the system's resolver.
A small and temporary fix for linux based distro's to fix dns leaking when using the XMPP protocol: http://drwhax.tumblr.com/post/4507494688/pidgin-and-tor
Replying to DrWhax:
Replying to katmagic:
When Pidgin connects to an XMPP server, it makes a DNS request using the system's resolver.
A small and temporary fix for linux based distro's to fix dns leaking when using the XMPP protocol: http://drwhax.tumblr.com/post/4507494688/pidgin-and-tor
While it's a useful work around, it's not likely that any TBB or TIMBB user will be able to do this without administrative rights.
Trac:
jabber.c-dns.patchTrac:
jabber.h-dns.patchThese patches appear to fix the leaks in http://developer.pidgin.im/ticket/11110 for jabber related DNS leaking.
Can someone please test this patch?
Trac:
Parent: N/A to #2918 (closed)Trac:
Summary: Pidgin leaks DNS requests when using the XMPP protocol. to Audit jabber/XMPP support for pidgin
Description: When Pidgin connects to an XMPP server, it makes a DNS request using the system's resolver.to
Pidgin leaks DNS requests when using the XMPP protocol.
When Pidgin connects to an XMPP server, it makes a DNS request using the system's resolver.
This is also our general ticket for auditing Jabber/XMPP support in Pidgin - if we find that it's safe, we'll be ready to enable it in TIMBB again.
I tested the latest Pidgin release (2.8.0) with the Tor proxy option added and while it can be set globally, you can only force encrypted logins on a per-account basis. Robert pointed out on IRC that it would be difficult to have a globally set option for this in Pidgin because of the variation in protocol specificities, but we should ask the Pidgin developers if there's any way to pre-seed it for a few IM types (our initial re-integration ones: GTalk, AIM, and XMPP), either by having a dummy accounts.xml or some other way.
Now that we can tell Pidgin to never perform direct (unproxied) DNS SRV queries, we need to either (a) teach Pidgin to perform the SRV query it needs for XMPP using DNS-over-TCP over Tor (and pick a TCP-capable DNS server for Pidgin to use, so it won't connect to the user's system-wide DNS resolver (i.e. the user's ISP) over Tor), or (b) provide a separate tool to perform the required SRV query and tell users how to feed the results to Pidgin and tell users how to find and use that tool.
If we decide to provide a separate tool (possibly as a stopgap solution), the DNS SRV query is for the ‘hostname’
_xmpp-client._tcp.gmail.com, and the resulting hostname and port go in the ‘Connect server’ and ‘Connect port’ fields, respectively, on the ‘Advanced’ tab of Pidgin's account settings dialog. (I don't know how to parse the hostname and port out of the SRV reply.)See [pidgin-gtalk-dns-queries-2011-05-26-01-summary-lines.txt pidgin-gtalk-dns-queries-2011-05-26-01-summary-lines.txt] for a Wireshark packet-summary dump of Pidgin performing the SRV query required for an XMPP account on
gmail.com.Replying to erinn:
I tested the latest Pidgin release (2.8.0) with the Tor proxy option added and while it can be set globally, you can only force encrypted logins on a per-account basis. Robert pointed out on IRC that it would be difficult to have a globally set option for this in Pidgin because of the variation in protocol specificities, but we should ask the Pidgin developers if there's any way to pre-seed it for a few IM types (our initial re-integration ones: GTalk, AIM, and XMPP), either by having a dummy accounts.xml or some other way.
I use hidden services that do not support SSL. It would be nice if it was turned on by default but I need the option to use "insecure" services when I actually know better than Pidgin could ever know.
asn said he'd look into this as a possible issue: http://sock-raw.org/papers/abusing_network_protocols
Replying to ioerror:
asn said he'd look into this as a possible issue: http://sock-raw.org/papers/abusing_network_protocols
It seems like: http://pidgin.im/pipermail/commits/2011-May/019293.html saves the day. Basically, pidgin will use the account proxy even for proxy connections; and if there is no account proxy it uses the global proxy (which the Tor pidgin option thing is).
I also asked in the pidgin dev XMPP room and they confirmed that pidgin uses the account/global proxy options for connecting to other proxies.
Replying to ioerror:
I think that we don't need to write anything new - we simply do not support XMPP related DNS SRV requests at this time.
Let me translate that into user-speak:
tor im browser bundle doesnt work
Users won't know that they need to perform a DNS query by hand. They won't even know what that means. Thus, we need to make Pidgin perform the DNS SRV queries it needs for XMPP through Tor, using DNS-over-TCP.
Is there any progress on this one? Can you/will you fix it? Or can't it be fixed or have you given up on it? There is no news about the Tor Browser IM Bundle for a long time.
When this can't be fixed, see #5498 (closed) for my very alternative proposal.
Trac:
Username: xnyhps
Cc: amnesia@boum.org to amnesia@boum.org, tor@xnyhps.nlReplying to proper:
Is there any progress on this one? Can you/will you fix it? Or can't it be fixed or have you given up on it? There is no news about the Tor Browser IM Bundle for a long time.
It's just a matter of testing the build that Erinn produced - I've been too busy to do it because it requires a copy of Windows. I'll try to get a Windows VM up and test the basic DNS leaking issues with xmpp in the next week.
When this can't be fixed, see #5498 (closed) for my very alternative proposal.
These issues are orthogonal, I think.
-
Trac:
Username: rubin110
Cc: amnesia@boum.org, tor@xnyhps.nl to amnesia@boum.org, tor@xnyhps.nl, rubin@starset.net -
If you guys think it has a strong chance of working, I'd be willing to help with testing on a live/used-daily system. I'm a busy CS student, so not sure how much help I can be with debugging, but it might be better than nothing.
Trac:
Username: minifig404
Cc: amnesia@boum.org, tor@xnyhps.nl, rubin@starset.net to amnesia@boum.org, tor@xnyhps.nl, rubin@starset.net, proegssilb@gmail.com -
Replying to ioerror:
It's just a matter of testing the build that Erinn produced - I've been too busy to do it because it requires a copy of Windows. I'll try to get a Windows VM up and test the basic DNS leaking issues with xmpp in the next week.
What build are you speaking of? Pidgin or Tor? Or should I attempt to build this from scratch for Windows with the linked to patches?
Currently running the tor-browser-2.2.35-8_en-US bundle with Pidgin 2.10.3 (libpurple 2.10.3) on Windows 7, with "Server" populated in the Advanced tab, seeing DNS leaks.
Trac:
Username: rubin110 -
So after scratching my brain for a bit, actually rereading much of this thread, and a bit of retesting...
The new build people have been speaking of is Pidgin, the change is a new item in the proxy type menu called "Tor/Privacy (SOCKS5)" which seems to push DNS through Tor.
Via the XMPP connection protocol I'm able to make successful connections to CCC's jabber server and talk.google.com without any DNS leakage.
The "GTalk" connection protocol uses gmail.com as the server, which seems to choke on making SRV look ups. This is also the case if gmail.com is used as the server in the XMPP connection protocol. Basically it fails to connect but with no DNS leakage.
I don't know if whoever packages this could simply rebuild Pidgin with talk.google.com in the server spot by default for GTalk instead of gmail.com. Additionally I have the feeling if the exit node is terminating out of Germany, gmail.com wont actually work, but I could be wrong.
Also tested under the new Tor/Privacy proxy type was chatting over AIM, which worked without issue. Is Tor planning to support any other IM protocols? If so I can quickly test the rest of those out too.
I'm going to poke file transfers and other forms of possibly leakage in a bit, with a primary focus on XMPP through CCC and talk.google.com.
Trac:
Username: rubin110 Replying to rubin110:
So after scratching my brain for a bit, actually rereading much of this thread, and a bit of retesting...
The new build people have been speaking of is Pidgin, the change is a new item in the proxy type menu called "Tor/Privacy (SOCKS5)" which seems to push DNS through Tor.
Right - exactly so.
Via the XMPP connection protocol I'm able to make successful connections to CCC's jabber server and talk.google.com without any DNS leakage.
Great. In theory - this should be be the default mode.
The "GTalk" connection protocol uses gmail.com as the server, which seems to choke on making SRV look ups. This is also the case if gmail.com is used as the server in the XMPP connection protocol. Basically it fails to connect but with no DNS leakage.
Yes, that is expected and this confirms the goal of the patch.
I don't know if whoever packages this could simply rebuild Pidgin with talk.google.com in the server spot by default for GTalk instead of gmail.com. Additionally I have the feeling if the exit node is terminating out of Germany, gmail.com wont actually work, but I could be wrong.
In theory, yes - though in practice, I think we need to set the connect server to talk.google.com and the main server to gmail.com - eg you@gmail.com but connecting through talk.google.com over Tor.
Also tested under the new Tor/Privacy proxy type was chatting over AIM, which worked without issue. Is Tor planning to support any other IM protocols? If so I can quickly test the rest of those out too.
If they are confirmed to not leak, yes. There are subtickets - if you do the review, they can be added into the bundle. At first glance, I think that AIM is fine except that their data retention policy is HORRIBLE as far as chatting goes.
I'm going to poke file transfers and other forms of possibly leakage in a bit, with a primary focus on XMPP through CCC and talk.google.com.
Sounds good. XMPP is first, feel free to do others after that...
Rubin,
I re-read this thread with confusion because I knew I made a Tor IM bundle pre-built with pidgin and didn't see it anywhere here (and this is the build ioerror was referring to). But there is actually a whole other bug! Please see #2918 (closed) -- it has the test IM bundle with IRC, Jabber, and AIM enabled (if I remember correctly). That's the thing you're supposed to test, sorry you had to go through all that trouble up there.
I can't figure out how to link to a specific comment, but it's number 27 and the link to the (very outdated) bundle is here: http://erinn.org/~e/tor-im-browser-2.2.33-3-UNOFFICIAL_en-US.exe
-
With Erinn's Tor IM bundle I'm able to make complete connections to CCC's jabber server, no problem, no leakage. This is with all of the proxy settings preconfigured out of the box.
Connecting to a gmail account fails as expected with the default settings due to SRV look up choke.
What's interesting now is that connecting to talk.google.com for a username@gmail.com account, the server returns with an SSL cert for gmail.com.
Accept certificate for talk.google.com? The certificate for talk.google.com could not be validated. The certificate claims to be from "gmail.com" instead. This could mean that you are not connecting to the service you believe you are.
The user is proivded buttons to "View Certificate...", accept or reject. If you view...
Common name: gmail.com Fingerprint (SHA1): 78:42:95:7e:7a:28:28:c1:88:b9:8d:5a:2a:d4:a5:78:3e:8a:21:06 Activation date: Thu Jan 19 17:05:56 2012 Expiration date: Sat Jan 19 17:15:56 2013
I'm about 99% sure I didn't simply click through any sort of SSL warning 2 weeks ago when I tested this last. Additionally Pidgin running for me personally (configured to poke talk.google.com) under Debian Sid hasn't thrown up any SSL cert errors. Does anyone else see this?
Trac:
Username: rubin110 -
Mostly related to @gmail.com accounts via XMPP...
After not being able to sleep over this I've completed a little bit more research and poked some fine folks on IRC regarding what the default behaviors here should be.
There are three basic fields that Pidgin presents to the user for the XMPP protocol, two of which must be populated to make any connection.
Username Domain Connect server (in most cases optional)
I'll referring to them in this comment with the first letter capitalized for each field. The Domain is also called the jid server.
Example 1: @gmail.com with SRV look up
Let's say Jane has a gmail account, her email address is jane@gmail.com, which Google refers to as also her Google Talk account name. From that Jane can populate the fields as such...
Username: jane Domain: gmail.com Connect server: [blank]
Pidgin takes the content in the Domain field, and attempts an SRV look up to see what server it should talk to. In the case of Tor this would fail, which at that point I'm pretty sure pidgin gives up and attempts to use the A record for that domain (such as the case with jabber.ccc.de). Once Pidgin has an IP address it should talk to, it attempts a STARTTLS handshake, makes sure the domain referred to in the cert matches up with the Domain field in Pidgin's account settings we listed above (gmail.com), checks to make sure the cert is valid, and progresses along completing the XMPP connection.
Now again, this would all fail through Tor due to the SRV request if Jane was using gmail.com as her Domain.
Example 2: @example.com hosted through Google Apps for Domains without SRV lookup
Jane also owns example.com, and has setup a Google Apps for Domains account with Google, turning on GTalk for her domain. Her email address is jane@example.com. If she wanted to use a 3rd party client to connect to the XMPP service, Google recommends that she populates the fields in Pidgin as such...
Username: jane Domain: example.com Connect server: talk.google.com
If the Connect server is populated Pidgin ignores making an SRV look up on the Domain address all together and connects directly to the Connect server address, which sort of solves that previous issue with Tor. Pidgin tells talk.google.com that the jid server (Domain) it wants to discuss is example.com. talk.google.com then sends back a an SSL cert for talk.google.com.
At this point we hit our first discrepancy. What I was informed in #jabber on freenode should happen is that the XMPP client should compare that certificate to whatever is populated in the Domain field, namely the jid server. This is mainly to combat a man in the middle attack sending out bogus addresses when an SRV response happens. If the Connect server field is populated too, the XMPP client should still compare the cert to the Domain field. Additionally the server should only send an SSL cert specified for the Domain (jid server) and not whatever host address the server is running off of.
This is discussed within the Pidgin project apparently a number of times, their take on it is slightly different. If no Connect server is provided, the cert should of course be verified against the Domain. But if a Connect server is provide, the cert should be verified against that. There was discussion about using the Domain as fall back, if verification against the Connect server failed, but I can't find any references of that being implemented. So Pidgin is expecting to see a cert made out for the Connect server host address and not the Domain (jid server).
So in Jane's case, Pidgin starts a handshake with talk.google.com (after sending some Jabber XML stating what jid server (Domain) she was talking about), a cert is handed down with talk.google.com in the commonName field, Pidgin verifies this against the Connect server field, it's a match, Jane continues on with sign-in and wins. Additionally if she's using Tor, all this works since there's no SRV look up. Jane double wins.
Regardless of what the Domain (jid server) is, Google will always respond back with talk.google.com. Again from my understanding of the XMPP spec as explained to me by #jabber, this is incorrect behavior and the server should actually provide an SSL cert for the address listed in Domain, specifically the jid server. Wile this isn't correct, Pidgin is fine with it since it actually doesn't care about the Domain if the Connect server field is populated, which also isn't correct. Two wrongs make a right?
Example 3: @gmail.com without SRV look up
Jane lied, she doesn't own example.com. Her Google account is jane@gmail.com, and she wants to use Tor. She configures Pidgin as such to get around the SRV look up limitation...
Username: jane Domain: gmail.com Connect server: talk.google.com
So Pidgin should now connect to talk.google.com, tell the server that the jid server (Domain) it's wanting to talk about is gmail.com, and expect a nice cert. The second discrepancy here is on Google. With every other hosted domain they'll provide an SSL cert with talk.google.com in the commonName, regardless of what the jid server (Domain) specified is. Sadly that's not the case if the Domain field is populated with gmail.com, talk.google.com will respond back with a cert for gmail.com. While that's actually the expected behavior (as stated by #jabber), Pidgin isn't expecting this. gmail.com from the cert and talk.google.com from the Connect server field are a mismatch, Pidgin doesn't bother to fall back to the Domain field, Pidgin throws an error up as stated in my previous bug. Jane turns into a scared child who is frightened by phrases like "could not be validated" and decides today isn't the day she uses the internet.
So where to go from here. First off the only way Pidgin can make a connection to Google's XMPP service is through the talk.google.com server, so when Gtalk is selected as a protocol we would need to auto populate the Connect to field with talk.google.com.
For the SSL issue, I'm doubtful Google will change anything on their end. I think after I get done writing this comment, I'll see about starting a bug on Pidgin's trac asking if it's possibly to implement the fall back to Domain option for cert verification that was discussed in the first bug I'm linking to at the bottom of this comment.
Other than that, no leakage, I'll see about testing out a little bit of AIM and IRC tonight.
http://developer.pidgin.im/ticket/6516 http://developer.pidgin.im/ticket/14614 http://developer.pidgin.im/ticket/14774
Trac:
Username: rubin110 -
Fallback to jid server fails when hitting an SSL cert mismatch with connect server address http://developer.pidgin.im/ticket/15111
Trac:
Username: rubin110 -
Just wanted to mention that there is a 4th case for GTalk: old-style SSL on port 5223 (seems to also work over 443). When connecting there, Google always responds with a certificate for talk.google.com, even when it later turns out the user was using a GMail-account. So this would currently work in both the GAFYD case and the GMail case, and can be done if you want to avoid patching Pidgin.
(Old-style SSL also means the domain a user wishes to use is not transmitted in plain text, contrary to the case of STARTTLS, but I'm not sure if this is really something for you to be concerned about.)
Trac:
Username: xnyhps
