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]
Message-ID: <430C9062.7050304@gmail.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ