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] [thread-next>] [day] [month] [year] [list]

Date: Wed Aug 24 16:20:35 2005
From: jftucker at gmail.com (James Tucker)
Subject: talk.google.com

I think the more important point to be maintained is that this is a 
Jabber server.
Interesting note: It's rdns is toolbar.google.com, but the jabber can be 
found at talk.google.com:5222.

Google created a custom authentication module (from packet capture with 
the standard win32 google talk client):

RECV: <?xml version="1.0" encoding="UTF-8"?><stream:stream 
from="gmail.com" id="<!--edit-->" 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>
SEND: <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" 
mechanism="X-GOOGLE-TOKEN"><!--edit: long encrypted string here--></auth>
RECV: <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>

This is quite different from the PLAIN mechanism which is used by most 
other clients currently.

Besides the potential financial impacts, bringing Jabber into such 
exposure, so quickly as only google can do, may increase general public 
interest in Jabber. This is always an interesting transition period for 
any technology, particularly in the security sector. This is no 
reflection on the development status of Jabber, it's just fact.

The other important thinking is the potential for incorporation of 
Jabber portals into other IM protocols for cross-protocol IM 
fucntionality in response to another major contender. This would 
probably be the most reliable method for these companies to maintain 
clients, however it would require a significant effort of co-ordination. 
If this is more what google want's to achieve then I would be most 
happy, but clearly it's wishfull thinking right now.