第3方client连接talk.google.com的一些注意之处

第3方client连接talk.google.com的一些注意之处 作者： InterMa   来源： 博客园   发布时间：2006-12-07 01:18  阅读：1436 次   原文链接    [收藏]    最近闲着没事，想用python写一个CUI的XMPP客户端，Server就用google的talk.google.com了，在google的Open Communications 上获得以下信息： The service is hosted at talk.google.com on port 5222 TLS is required The only supported authentication mechanism is SASL PLAIN 但是经过测试，dump了一下XMPP Stream，发觉实际的情况没这么简单，dump的具体过程就不废话了（用gaim来dump，:-)），得出的具体结论如下： 【1】talk.google.com:5222：    这个地址应该主要是给gtalk用的，因为首先这个地址不支持SASL:PLAIN认证，只支持google自己的X-GOOGLE-TOKEN认证（关于X-GOOGLE-TOKEN认证，详见 这里 ）。其次就是无法以SSL(TLS)方式连接（错误提示：error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol，这里已经搞清楚了因为python没有内置StartTLS功能的模块 ，:-<）。因此不支持TLS handshake(StartTLS) 的第3方客户端建议不要连这个地址。 【2】talk.google.com:5223： 和上个地址正好相反，这个地址只支持以SSL(TLS)方式进行连接。以SSL(TLS)方式连接之后，发现它支持SASL:PLAIN和X-GOOGLE-TOKEN认证，因此我们自己写的第3方客户端连这个地址就可以了。 2006年12月7日重要更新： 今天在psi-im的wiki 上获得了一个重要信息： In the Jabber world, these two terms are used as following: SSL support: communication using SSL or TLS protocol, on port 5223 , without handshaking - the stream is encrypted from the very beginning. TLS support: communication using SSL or TLS protocol, on port 5222 , with handshaking (also known as StartTLS ) - the encryption type is first negotiated in plain text and afterwards the stream is encrypted. 这下就没什么可说得了，上边说得很清楚了。 5222口在TLS handshake之后，就支持PLAIN验证了（感谢linux@bmy ，同时打算和他搬到这里 ，用C开发了），错怪google了，:-) 此文只保证现状如此（同时本人分析过程仅供参考），不保证一定正确且对未来的变化没有任何担保，:-P           谈google talk的加密问题

作者：佚名 文章来源：不详 点击数： 更新时间：2007-1-25 11:22:42

google已经成为互联网上的一面旗帜，无论有什么举动都会引人注目。最近几天大家都在讨论google talk，我今天才装上，已经算是慢一拍了。 装上之后才发现，安装目录下居然只有两个文件，一个是googletalk.exe，一个是uninstall.exe。google一贯的简洁风格在这里就体现出来了。 google talk用了标准的jabber协议 ，所以兼容很多其它的IM软件。google做了一个页面，专门告诉你哪些别的软件可以用google talk服务，并且很详细地教你设置。这份大家风范令我肃然起敬，又不禁想起来微软那个教你如何在防火墙 上封掉MSN的KB。气度这种东西，不是有钱没钱的问题，也不是一天两天能学会的。 san对google talk的通信抓了包，发现会话数据都是不加密的，也就是说，控制网络 的人，就能控制你的对话。 我觉得有些奇怪，jabber协议 本身是可以选择加密的，而google为gmail提供了256位的加密，没道理这个就不加密。 于是我用Gaim连接google talk服务，并且在连接选项中要求加密。这时候再抓包就可以看到，所有通信都是加密的。 也就是说，google talk服务器支持加密，但是目前测试版的官方客户端还不支持。未来也许会改变吧。 PS： 我估计对google talk用stunnel应该是可以的，不过没有测试。google talk连接的服务器是硬编码在程序内部的，如果想用stunnel，要么修改程序，要么修改host文件，把talk服务器指向跑stunnel的机 器。有兴趣的可以试一下。 晚上吃饭的时候，我想应该找一个既能用标准客户端，又能加密通信，还要简便易行，老少皆宜的法子出来。要不然总觉得有点对不起观众。 我对jabber协议 一无所知，也不打算花时间去看文档，索性就硬上。先抓gaim的加密通信包和官方客户端的非加密包看看再说。 官方客户端的身份认证是通过gmail.com来做的，这个过程基于HTTPS，是加密的；聊天数据通过talk.google.com，不加密。 Gaim的认证和聊天都通过talk.google.com，而且必须选择加密。talk.google.com不支持非加密的身份认证过程。 奇 怪的是，无论是加密还是不加密，聊天数据都是通过talk.google.com的5222端口。根据抓包看到的数据，和对5222手工SSL协商失败这 个结果来看。jabber所支持的加密方式和HTTPS、POPS等是不完全一样的。也就是说，不能简单的通过stunnel来建立加密隧道。 事情就这样结束了么？当然不会，否则我现在一定正在郁闷，而不是写这篇文档。 像 我这种人，看到一个5222端口，就不可能不去看看有没有5221、5223、5224……这是多少年养成的习惯。我发现talk.google.com 上就有5223和5224端口。简单测试了一下，发现这两个端口都支持标准SSL协商。那么这能用否这两个端口进行通信呢？ 我做了下面这几件事： 1、在机器上的%SyetemRoot%/system32/drivers/etc/hosts中加了这一行： 127.0.0.1 talk.google.com 2、在stunnel.conf中加了这些： [Google Talk] accept = 127.0.0.1:5222 connect = talk.google.com:5223 然后重新启动Stunnel，再运行google talk。 OK，现在google talk完全可以正常使用，并且这时所有来往的数据都是经过加密的。 看我blog的朋友不一定都搞技术 ， 所以这里科普一下：上面做的第一件事是让google talk客户端认为我本机就是聊天服务器talk.google.com；第二件事是在本机建立了一个加密隧道，google talk用非加密数据和本机的Stunnel通信，Stunnel把数据加密后传递给能接收标准SSL加密的talk.google.com:5223， 并把服务器的加密数据解密后交给google talk客户端。 打个比方，google talk是一个只会说汉语的人，Gaim懂意大利语，Stunnel既懂汉语又懂阿拉伯语，talk.google.com:5222懂意大利语和汉语，talk.google.com:5223只懂阿拉伯语。 现 在我们要和talk.google.com说话。虽然google talk和talk.google.com:5222可以直接用汉语沟通，但是这样会被偷听。所以我们让google talk先把要说的话用汉语告诉Stunnel（这个过程是在自己家完成的，不会被偷听），然后Stunnel用阿拉伯语对 talk.google.com:5223转述。或者，用Gaim和talk.google.com:5222说意大利语也是一个选择。 PS：又看了一下google的文档，这个5223是为了兼容某些jabber客户端而留的。可能目前就是有两种jabber加密方式并存，不同客户端用了不同方式。 文档里面没有提5224，以我恶毒的心来揣测，估计是因为加密对系统 负担比较大，google的人特意开了这个口给熟人用的，这个没什么人用的端口速度应该比较快——哈哈哈哈，纯属玩笑。