[tor-bugs] #1676 [Tor bundles/installation]: Audit jabber/XMPP support for pidgin
Tor Bug Tracker & Wiki
torproject-admin at torproject.org
Sat May 12 03:47:00 UTC 2012
#1676: Audit jabber/XMPP support for pidgin
--------------------------------------+-------------------------------------
Reporter: katmagic | Owner: ioerror
Type: defect | Status: assigned
Priority: critical | Milestone:
Component: Tor bundles/installation | Version:
Keywords: pidgin, DNS | Parent: #2918
Points: | Actualpoints:
--------------------------------------+-------------------------------------
Comment(by 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 at 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 at 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 at 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
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1676#comment:41>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list