神马文学网再谈google talk的加密问题
来源：百度文库 编辑：神马文学网 时间：2024/04/28 10:33:50
再谈google talk的加密问题
作者：tombkeeper
下午写了一篇《talk about google talk》，里面提到，虽然google talk本身还不支持加密，但是目前至少用Gaim这样的客户端已经可以进行加密通信了。
晚上吃饭的时候，我想应该找一个既能用标准客户端，又能加密通信，还要简便易行，老少皆宜的法子出来。要不然总觉得有点对不起观众。
我对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的人特意开了这个口给熟人用的，这个没什么人用的端口速度应该比较快——哈哈哈哈，纯属玩笑
作者：tombkeeper
下午写了一篇《talk about google talk》，里面提到，虽然google talk本身还不支持加密，但是目前至少用Gaim这样的客户端已经可以进行加密通信了。
晚上吃饭的时候，我想应该找一个既能用标准客户端，又能加密通信，还要简便易行，老少皆宜的法子出来。要不然总觉得有点对不起观众。
我对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的人特意开了这个口给熟人用的，这个没什么人用的端口速度应该比较快——哈哈哈哈，纯属玩笑
再谈google talk的加密问题
简洁的华丽 google talk
Google Talk---Google 发布的IM产品
google talk
简洁的华丽 google talk - pchome.net
google talk正式发布
东拉西扯：Google不talk
美丽的google talk——回复三句半
用Google Talk与你的MSN联系人对话
美丽的google talk——回复三句半 - 苦咖啡豆
ada’s blog 艾达思语 ?google的野心—-google desktop 2 + google talk
替Google Talk更换皮肤
Google Talk技巧十则
网页版Google Talk发布
Google Talk技巧十则
Google加密搜索的另一种解决方案-月光博客
GTalk的自定义皮肤OR主题！layer|twenty|two iChat skin for Google Talk
一台电脑同时运行多个Google Talk的方法
How to configure Gaim for Google Talk?
个性聊天 Google Talk Gadget解析
效法Google Talk 雅虎电子信箱整合即时通讯
Google Talk中英文翻译机器人试用
Google提供SSL加密搜索服务-Google SSL 加密
巧妙“加密”Google文档内容