full-disclosure - talk.google.com

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Fri Aug 26 11:21:30 2005
From: jftucker at gmail.com (James Tucker)
Subject: talk.google.com

Sorry, I know this is continuing off topic, but here's a log with some
description to clear up the statement below. Note, every line beginning
+ is client outbound data, and everything begging - is client inbound data:

+ <?xml version="1.0"?><stream:stream to="gmail.com"
xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams"
xml:lang="en" version="1.0">
- <?xml version="1.0" encoding="UTF-8"?>
- <stream:stream from="gmail.com" id="<!--EDIT: DATA REMOVED-->"
version="1.0" xmlns:stream="http://etherx.jabber.org/streams"
xmlns="jabber:client">
- <stream:features><starttls
xmlns="urn:ietf:params:xml:ns:xmpp-tls"/><mechanisms
xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>X-GOOGLE-TOKEN</mechanism></mechanisms></stream:features>

Here, the google client would start authenticating, however, my client
doesn't know about the X-GOOGLE-TOKEN mechanism. My client doesn't do
strict checking of the mechanisms here, and requests a new auth session
anyway.

+ <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls" />
- <proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>
+ <?xml version="1.0"?><stream:stream to="gmail.com"
xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams"
version="1.0">
- <?xml version="1.0" encoding="UTF-8"?>
- <stream:stream from="gmail.com" id="<!--EDIT: DATA REMOVED-->"
version="1.0" xmlns:stream="http://etherx.jabber.org/streams"
xmlns="jabber:client">
- <stream:features><mechanisms
xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism><mechanism>X-GOOGLE-TOKEN</mechanism></mechanisms></stream:features>

Google now offer us a PLAIN mechanism in the second instance.

+ <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl"
mechanism="PLAIN"><!--EDIT: DATA REMOVED--></auth>
- <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>

And we're authed, using PLAIN. This string is short, and not entirely 
human readable, but the mechanism is well documented. The security 
implications of this are simple, the Google Talk client uses a more 
secure authentication method, period.

+ <?xml version="1.0"?><stream:stream to="gmail.com"
xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams"
version="1.0">
- <?xml version="1.0" encoding="UTF-8"?>
- <stream:stream from="gmail.com" id="<!--EDIT: DATA REMOVED-->"
version="1.0" xmlns:stream="http://etherx.jabber.org/streams"
xmlns="jabber:client">
- <stream:features><bind
xmlns="urn:ietf:params:xml:ns:xmpp-bind"/><session
xmlns="urn:ietf:params:xml:ns:xmpp-session"/></stream:features>
+ <iq type="set"><bind
xmlns="urn:ietf:params:xml:ns:xmpp-bind"><resource>GoogleIM</resource></bind></iq>

I left the last few lines, really for the last one in particular. Notice
the resource, I have seen many people getting this wrong. On that note,
also notice the values of attributes 'to'. Your username is your google
account username, not your gmail address, your JID however, is your
gmail address. The other problem experienced is if your client will not
disable SRV DNS lookups, records for which are not available for the
google talk service.

And that's it for this topic. Cheers.

Andre Protas wrote:

>The Server does not accept plain.  Actually, some clients were unable to
>connect to the jabber server b/c of that.  Gajim was one.
>
>Anyone get a perl/python jabber client connecting to talk.google.com
>properly?
>
> 
>Signed,
>
>Andre Derek Protas
>Security Researcher
>eEye Digital Security
>aprotas eeye com
>  
>