[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #1676 [Tor bundles/installation]: Audit jabber/XMPP support for pidgin



#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@xxxxxxxxx,
 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@xxxxxxxxxxxx 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@xxxxxxxxx, 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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs