【注意】中文版Google Talk是未加密明文传输聊天内容
wanghx
如果只有中文版这样，这算 google 作恶的一个罪证。是否 google 中文软件部门配合暴政的恶行？
http://initiative.yo2.cn/archives/642153
在 八 卦小组 看到一个令人震惊的消息：中 文版Google Talk是明文传输聊天内容，我验证了一下，的确是明文，截图如下：
请各位Google Talk用户注意鉴别阉割版，老大哥在注视着你！
记得以前wikipedia说
过，Google官方承认Google Talk的end-to-end的聊天是未加密的并不能保证一个终端
到另一个终端都是加密的。
[...] that the connection between the Google Talk client and the Google Talk
server is encrypted. This prevents others from seeing your mail
notifications, Friends list, and other personal settings. The
encryption also prevents others from seeing messages between your
desktop and Google's servers. However, encryption is not end-to-end, so
there is no guarantee that the messages are encrypted when sent to
another user. IMs will not be encrypted in these scenarios:- Sender/recipient is using Gmail's chat features over HTTP
- Sender/recipient is on a federated network that doesn't support
encryption
- Sender/recipient is behind IMLogic or another similar proxy
具体什么是end-to-end，我猜应该是p2p的libjingle某
些情况下是直接未加密传输的吧？ 也就是说，如果
你用的是英文版的Google Talk，那么Google
Talk从你桌面到Google服务器是加密的，但是从Google服务器出去，到你聊天对象那里加密与否，Google不能保证。
其他未加密的情况有：通过http的Gmail测栏聊天；通过IMLogic等代理 登录GTalk；你所在的XMPP federation不支持加密。
下面具体说明一下我所知道的 GoogleTalk 各个版本加密与否情况：
中文版 Google Talk（安装文件URL）
1.0.0.105，使用的未加密明文传输XMPP
英文版 Google Talk（安装文件URL）
1.0.0.104 则是TLS加密，一般来说无法破解和嗅探
Google Talk Labs Edition（安装文件URL）1.0.267.233，
看了下，使用的也是明文传输，不是通过XMPP协议，而是普通HTTP GET和HTTP POST，通讯网址是
http://talkgadget.google.com/talkgadget/msg
Gmail侧栏和iGoogle里嵌入的Google Talk，以及Google Talk Gadget和网站连接方式和网页制作设定有关。一般来说网页是https://开头的就是加密的。普遍国内 Gmail 用户使用https的习惯还是有的吧？
第三方XMPP客户端（例如pidgin）登录GTalk的，选择TLS就算加密。
长期用英文版还没注意到这个严重的问题，直到有人说抓包发现Google Talk是明文。才发现中文版居然是未加密的。汗死！这一点谷歌算作恶了吧？明明知道国内网络环境不太好的，居然还把 加密取消了，也不说明一下。
更新
根据抓包的情况来看，有一个方法估计可以屏蔽中
文GTalk，Jabber ID（JID）是由node@domain/resource 这个格式构成的，XMPP客户端可以尝试屏蔽（如果支持的话）以Talk.v105 开头的resource。目前我也没有具体步骤，只是说这个可能实现的
原理。
6 Responses to “【注意】中文版Google Talk是未加密明文传输聊天内容”
- duola Says:
八月 25th, 2009 at 22:14老大哥监视着我，他要干什么呢
- monnand Says:
八月 25th, 2009 at 22:35XMPP提供的是下层通信协议。上层的加密完全可以在通信双方进行协议，这 样更加灵活，安全。
试想：通信双方实现协定好加密算法和密钥，通过XMPP协议，利用gtalk传输。这样即便中途信息被劫持，也很难破解。
我们再看看QQ：通信的每一方和服务器协商一个密钥，全部信息都转发给服务器，服务器解密后再加密传送给目的端。换句话说，服务器完全控制着加密的全部流 程。随时可以过滤。你不信？多少人都是因为QQ里面谈论敏感信息被请去喝茶，甚至成为法庭证据啊。 - Hector Says:
八月 25th, 2009 at 22:53 - rogue Says:
八月 25th, 2009 at 22:55刚看了Miranda IM，默认已勾选“使用TLS”，应该是加密了吧？
- zola Says:
八月 25th, 2009 at 22:56用pidgin登录GTALK，再用上OTR插件，就可以实现加密的通讯 了，即使在GMAIL的chat目录也只能看到乱码。
- LiuXuFei Says:
八月 25th, 2009 at 23:10每天吃喝拉撒…
mon...@gmail.com
> 是不是 1.0.0.105 版本的通病呢？可以查一下 1.0.0.105 版本的英国版和其他语言版。美
> 国版只有 1.0.0.104。
> 如果只有中文版这样，这算 google 作恶的一个罪证。是否 google 中文软件部门配合暴政
> 的恶行？
>
gtalk下层采用XMPP协议，XMPP协议的目的是传输信息，加密层一般放置在传输层
以上。这种分层的方法在软件开发中是非常常用的。
这样，完全可以通过通信双发协定加密算法和密钥，来制定适合各自的策略。这种
方法更加安全，而且更加灵活。
试想：通信双方实现协定好加密算法和密钥，通过XMPP协议，利用gtalk传输。这
样即便中途信息被劫持，也很难破解。因为加密算法和加密密钥都是通信双方私下
协定的，中间人无法知道——除非加密算法本身有漏洞。
我们再看看QQ：通信的每一方和服务器协商一个密钥，全部信息都转发给服务器，
服务器解密后再加密传送给目的端。换句话说，服务器完全控制着加密的全部流
程。随时可以过滤。你不信？多少人都是因为QQ里面谈论敏感信息被请去喝茶，甚
至成为法庭证据啊。
使用gtalk的话，可以用pidgin加插件OTR正是这么做的
http://www.cypherpunks.ca/otr/
再看看这里： http://www.hx263.net/post/185.html
MSN也是明文传输。这一方面是方便调试（明文比加密后的内容更方便看懂，一般
写软件，加密部分一开始都是做成假的，调试的时候就直接能看到明文，而不必再
解密。等到产品release的时候，再打开加密功能。安全级别低的软件不加密是很
常见的），另一方面可以方便地根据用户需求，让通信双方制定各自的安全策略
（加密算法或密钥）。这一点本身就是XMPP的出发点之一（当然了，MSN不是用
XMPP）。XMPP是RFC标准协议，和google是否作恶没关系。如果真的要传输敏感消
息，建议按照 http://www.hx263.net/post/185.html 中的做法，加插件进行加
密。这些插件和pidgin都是自由/开源软件，源代码全部开放，因此不可能在其中
加入什么间谍代码。因为如果加入了，就代码就会被用户看到，而这些用户中很多
都是从事软件开发的，完全有可能从中发现间谍代码，删除掉，再编译运行。所以
在自由/开源软件内加入间谍代码是基本不可能的。
我打算最近发表一篇博客，就这个问题详细解释一下，争取让非专业人士也能读
懂。这期间还有什么问题，欢迎讨论。
> http://initiative.yo2.cn/archives/642153
> 八25
>
>
> 【注意】中文版Google Talk是未加密明文传输聊天内容
> <http://initiative.yo2.cn/archives/642153>
>
> Hacks <http://initiative.yo2.cn/archives/category/hacks>, software
> <http://initiative.yo2.cn/archives/category/software>Add comments <#respond>
>
> 在 /八卦小组/ 看到一个令人震惊的消息：*中文版*Google Talk是明文传输聊天内容，我
> 验证了一下，的确是明文，截图如下：
>
> 请各位Google Talk用户注意鉴别阉割版，老大哥在注视着你！
>
> 记得以前wikipedia <http://en.wikipedia.org/wiki/Google_Talk#Encryption>说过，
> Google官方承认Google Talk的end-to-end的聊天是未加密的并不能保证一个终端到另一个
> 终端都是加密的
> <https://groups.google.com/group/Calls-Chats-and-Voicemail/browse_thread/thread/431d561bf7d6f7d6/e49343f783a06a1e?
> lnk=gst&q=encryption&rnum=1#e49343f783a06a1e>。
>
> [...] that the connection between the Google Talk client and the Google Talk
> server is encrypted. This prevents others from seeing your mail
> notifications, Friends list, and other personal settings. The
> encryption also prevents others from seeing messages between your
> desktop and Google's servers. However, encryption is not end-to-end, so
> there is no guarantee that the messages are encrypted when sent to
> another user. IMs will not be encrypted in these scenarios:
>
> - Sender/recipient is using Gmail's chat features over HTTP
> - Sender/recipient is on a federated network that doesn't support
> encryption
> - Sender/recipient is behind IMLogic or another similar proxy
>
> 具体什么是end-to-end，我猜应该是p2p的libjingle
> <http://code.google.com/apis/talk/libjingle/index.html>某些情况下是直接未加密传
> 输的吧？ 也就是说，如果你用的是英文版的Google Talk，那么Google Talk从你桌面到
> Google服务器是加密的，但是从Google服务器出去，到你聊天对象那里加密与否，Google不
> 能保证。
>
> 其他未加密的情况有：通过http的Gmail测栏聊天；通过IMLogic等代理登录GTalk；你所在
> 的XMPP federation不支持加密。
>
> 下面具体说明一下我所知道的 GoogleTalk 各个版本加密与否情况：
>
> 中文版 Google Talk（安装文件URL
> <http://dl.google.com/googletalk/googletalk-setup-zh-CN.exe>） 1.0.0.105，使用的
> *未加密明文传输*XMPP
>
> 英文版 Google Talk（安装文件URL
> <http://dl.google.com/googletalk/googletalk-setup.exe>） 1.0.0.104 则是TLS加密，
> 一般来说无法破解和嗅探
>
> Google Talk Labs Edition（安装文件URL
> <http://dl.google.com/googletalk/labsedition/1.0.267.233/GoogleTalkLabsEdition.msi>）
> 1.0.267.233，看了下，使用的也是*明文*传输，不是通过XMPP协议，而是普通HTTP GET和
> HTTP POST，通讯网址是 http://talkgadget.google.com/talkgadget/msg
>
> Gmail侧栏 <http://mail.google.com/mail/help/chat.html>和iGoogle里嵌入
> <http://www.google.com/support/talk/bin/answer.py?hl=en&answer=126293>的Google
> Talk，以及Google Talk Gadget
> <http://googletalk.blogspot.com/2007/03/google-talk-gadget.html>和网站连接方式和
> 网页制作设定有关。*一般来说*网页是https://开头的就是加密的。普遍国内 Gmail 用户
> 使用https的习惯还是有的吧？
>
> 第三方XMPP客户端（例如pidgin）登录GTalk的，选择TLS就算加密。
>
> 长期用英文版还没注意到这个严重的问题，直到有人说抓包发现Google Talk是明文。才发
> 现中文版居然是未加密的。汗死！这一点谷歌算*作恶*了吧？明明知道国内网络环境不太好
> 的，居然还把加密取消了，也不说明一下。
>
> 更新
>
> 根据抓包的情况来看，有一个方法*估计*可以屏蔽中文GTalk，Jabber ID（JID）是由
> |node@domain/resource| 这个格式构成的，XMPP客户端可以尝试屏蔽（如果支持的话）以
> |Talk.v105| 开头的resource。目前我也没有具体步骤，只是说这个可能实现的原理。
>
>
> 6 Responses to “【注意】中文版Google Talk是未加密明文传输聊天内容”
>
> 1. duola <http://duolab.cn> Says:
> 八月 25th, 2009 at 22:14 <#comment-278978>
>
> 老大哥监视着我，他要干什么呢
>
> Reply <javascript:void(0)>
>
> 2. monnand <http://monnand.appspot.com> Says:
> 八月 25th, 2009 at 22:35 <#comment-278979>
>
> XMPP提供的是下层通信协议。上层的加密完全可以在通信双方进行协议，这样更加灵
> 活，安全。
> 试想：通信双方实现协定好加密算法和密钥，通过XMPP协议，利用gtalk传输。这样
> 即便中途信息被劫持，也很难破解。
> 我们再看看QQ：通信的每一方和服务器协商一个密钥，全部信息都转发给服务器，服
> 务器解密后再加密传送给目的端。换句话说，服务器完全控制着加密的全部流程。随
> 时可以过滤。你不信？多少人都是因为QQ里面谈论敏感信息被请去喝茶，甚至成为法
> 庭证据啊。
>
> Reply <javascript:void(0)>
>
> 3. Hector Says:
> 八月 25th, 2009 at 22:53 <#comment-278981>
>
> 会不会与此有关？
> http://wiki.freeswitch.org/wiki/Mod_dingaling#FreeSWITCH_and_Google_Talk_can.27t_get_connected_to_each_other_after_a_successful_ringing_and_answering
>
> Reply <javascript:void(0)>
>
> 4. rogue <http://rogue.yo2.cn> Says:
> 八月 25th, 2009 at 22:55 <#comment-278982>
>
> 刚看了Miranda IM，默认已勾选“使用TLS”，应该是加密了吧？
>
> Reply <javascript:void(0)>
>
> 5. zola <http://zuo.la/> Says:
> 八月 25th, 2009 at 22:56 <#comment-278983>
>
> 用pidgin登录GTALK，再用上OTR插件，就可以实现加密的通讯了，即使在GMAIL的
> chat目录也只能看到乱码。
>
> Reply <javascript:void(0)>
>
> 6. LiuXuFei <http://LiuXuFei.com> Says:
> 八月 25th, 2009 at 23:10 <#comment-278984>
>
> 每天吃喝拉撒…
>
> Reply <javascript:void(0)>
>
>
>
>
wanghx
w 写道:
是不是 1.0.0.105 版本的通病呢？可以查一下 1.0.0.105 版本的英国版和其他语言版。美 国版只有 1.0.0.104。这不是bug，是特性（feature）
如果只有中文版这样，这算 google 作恶的一个罪证。是否 google 中文软件部门配合暴政 的恶行？
gtalk下层采用XMPP协议，XMPP协议的目的是传输信息，加密层一般放置在传输层 以上。这种分层的方法在软件开发中是非常常用的。
这样，完全可以通过通信双发协定加密算法和密钥，来制定适合各自的策略。这种 方法更加安全，而且更加灵活。
试想：通信双方实现协定好加密算法和密钥，通过XMPP协议，利用gtalk传输。这 样即便中途信息被劫持，也很难破解。因为加密算法和加密密钥都是通信双方私下 协定的，中间人无法知道——除非加密算法本身有漏洞。
wanghx
这不是bug，是特性（feature）
gtalk下层采用XMPP协议，XMPP协议的目的是传输信息，加密层一般放置在传输层 以上。这种分层的方法在软件开发中是非常常用的。
这样，完全可以通过通信双发协定加密算法和密钥，来制定适合各自的策略。这种 方法更加安全，而且更加灵活。
试想：通信双方实现协定好加密算法和密钥，通过XMPP协议，利用gtalk传输。这 样即便中途信息被劫持，也很难破解。因为加密算法和加密密钥都是通信双方私下 协定的，中间人无法知道——除非加密算法本身有漏洞。使用gtalk的话，可以用pidgin加插件OTR正是这么做的 http://www.cypherpunks.ca/otr/
我们再看看QQ：通信的每一方和服务器协商一个密钥，全部信息都转发给服务器， 服务器解密后再加密传送给目的端。换句话说，服务器完全控制着加密的全部流 程。随时可以过滤。你不信？多少人都是因为QQ里面谈论敏感信息被请去喝茶，甚 至成为法庭证据啊。
再看看这里： http://www.hx263.net/post/185.html
MSN也是明文传输。这一方面是方便调试（明文比加密后的内容更方便看懂，一般 写软件，加密部分一开始都是做成假的，调试的时候就直接能看到明文，而不必再 解密。等到产品release的时候，再打开加密功能。安全级别低的软件不加密是很 常见的），另一方面可以方便地根据用户需求，让通信双方制定各自的安全策略 （加密算法或密钥）。这一点本身就是XMPP的出发点之一（当然了，MSN不是用 XMPP）。XMPP是RFC标准协议，和google是否作恶没关系。如果真的要传输敏感消 息，建议按照 http://www.hx263.net/post/185.html 中的做法，加插件进行加 密。这些插件和pidgin都是自由/开源软件，源代码全部开放，因此不可能在其中 加入什么间谍代码。因为如果加入了，就代码就会被用户看到，而这些用户中很多 都是从事软件开发的，完全有可能从中发现间谍代码，删除掉，再编译运行。所以 在自由/开源软件内加入间谍代码是基本不可能的。
我打算最近发表一篇博客，就这个问题详细解释一下，争取让非专业人士也能读 懂。这期间还有什么问题，欢迎讨论。
wanghx
不要轻视 opensource 软件被加入间谍代码的可能。当年 C 语言的设计者就曾在 C 编译器里加入间谍代码，使得所有经过其编译的 login 程序都会自动让他登录。:) 许多专业程序员想破脑袋最终才知道是 C 语言编译器就出了问题。现在随便一个软件的复杂度都很高，不可能所有代码都经过检查。隐藏一些复活节彩蛋，间谍代码之类的，轻而易举多年不会被发现。等到发现的时候，恐怕已经晚了。
wanghx
找到這哥們自己寫的帖子
www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
许志永被黑帮绑架 http://tr.im/vxqH
mon...@gmail.com
> 我理解你说的是什么意思，但是你误解了问题。
> 如果美国版是加密传送内容，而中文版特别不加密。这就是作恶的证据。
>
原文讲： ``也就是说，如果你用的是英文版的Google Talk，那么Google Talk从
你桌面到Google服务器是加密的，但是从Google服务器出去，到你聊天对象那里加
密与否，Google不能保证。''
这里有一个误解。我首先介绍一些google的思路：
我用S代表服务器，用p1, p2表示通信的双方。
对于QQ来说，通信过程是这样的。首先是登录：
p1 ---登录（加密）--->S;
S ---好友列表等信息（加密）--->p1
...p2登录过程类似
然后是互相传递消息（QQ用户之间）
p1 ---消息（加密）--->S ---消息（加密）--->p2
好了。可以看到，消息是通过服务器中转的。下面我们看看gtalk的通信过程：
登录依然类似：
p1 ---登录（加密）--->S;
S ---好友列表等信息（加密）--->p1
但是传递消息则不同——这就是为什么我说gtalk更加安全的原因。在登录的时候，
p1已经获得了p2的通信方式（或者可以通过运行中途询问服务器来获得）。那么消
息就可以直接地从p1到达p2。这也就是为什么gtalk讲p2p的原因。通信节点直接访问。
p1 ---消息（可选加密）--->p2
说到这里，我们再看看那博文上说：``也就是说，如果你用的是英文版的Google
Talk，那么Google Talk从你桌面到Google服务器是加密的，但是从Google服务器
出去，到你聊天对象那里加密与否，Google不能保证。''
这显然不是。我们选中了TLS加密，仅仅是说客户端与服务器之间使用TLS加密。这
一点从博文上引用的google官方资料就可以看出来：
that the connection between the Google Talk client and the Google Talk
server is encrypted. This prevents others from seeing your mail
notifications, Friends list, and other personal settings.
另外，我们也可以看到，下面也提到了端到端之间（通信双方）是不经过加密的：
However, encryption is not end-to-end, so there is no guarantee that the
messages are encrypted when sent to another user.
说到这里可以看出，无论是否使用TLS加密，都无法保证用户之间的通信是加密
的。我不用windows，所以没法测试官方的gtalk。我一直使用 pidgin，没有加
密，消息没被墙过。曾经用QQ的时候被和谐很多次——关键问题是，我们从上面的介
绍可以看出，QQ是使用服务器中转，换句话说，服务器永远能知道用户在说什么，
做什么。
我具体还没有做测试。等我闲下来可以把具体的测试内容写出来。到时候我们再继
续讨论这个问题。但是有一点是可以确认的：使用pidgin配合OTR插件，肯定是没
有问题的——除非加密算法存在漏洞。但是以GFW现在的能力来看，处理明文已然非
常费力，所以，哪怕加密算法理论上可破解（在有限且可接受的时间内），估计
GFW的网关也没能力破解了。因为识别加密算法估计就识别不出来——GFW面对的数据
流量非常大，任何小的改动都可能令它不堪重负。
> 至于加密的链接就无法调试的说法，也是不成立的。调试软件并不一定依靠截取报文，同时也可以打开调试选项，专门用不加密的方式来调试。
>
我没有说无法调试。我是说不方便调试。这里的调试并非是狭义地使用debugger，
而是广义地讲测试软件功能。具体信息参看Eric Raymond写的UNIX编程艺术，其中
提到了使用可读文本作为存储和传输的优点。这里我就不多说了。我举个例子：我
有两个软件，分别是服务器端（S）和客户端（C），我负责开发客户端，另一个人
负责开发服务器端。我想测试我的客户端是否能够正常收到服务器的消息，那么，
如果服务器端安排妥当（我是指部署和协议上），我可以使用现成的telnet来连接
服务器，然后明文发送消息。这样做最大的好处就是：我使用的telnet已经是经过
很长时间考验的软件。如果中途出现消息误传的问题，那么多半是服务器方的问
题。倘若服务器在此时加入加密算法，那么就无法使用telnet进行测试。当然，这
是具体软件开发方法的问题，我觉得没必要对此讨论太多。如果对这有兴趣，可以
单独开一个thread。
mon...@gmail.com
> : 这些插件和pidgin都是自由/开源软件，源代码全部开放，: 因此不可能在其中 加入什么间谍代码。因为如果加入了，
> : 就代码就会被用户看到，而这些用户中很多 都是从事软件开发的，
> : 完全有可能从中发现间谍代码，删除掉，再编译运行。
> : 所以 在自由/开源软件内加入间谍代码是基本不可能的。
>
> 不要轻视 opensource 软件被加入间谍代码的可能。当年 C 语言的设计者就曾在 C 编译器里加入间谍代码，使得所有经过其编译的 login
> 程序都会自动让他登录。:) 许多专业程序员想破脑袋最终才知道是 C 语言编译器就出了问题。
>
software的概念呢，更不要提open source了。不知道你从哪里来的八卦，我并不
是质疑它的真实性，而是不知道它跟自由/开源软件有什么关系。至少我敢保证，
现在的gcc里面肯定没这种东西。
> 现在随便一个软件的复杂度都很高，不可能所有代码都经过检查。隐藏一些复活节彩蛋，间谍代码之类的，轻而易举多年不会被发现。等到发现的时候，恐怕已经晚了。
>
谍代码的。复活节彩蛋倒是比比皆是。但是彩蛋和间谍代码完全是两个概念……至今
我没听说过哪个大型的自由/开源软件的项目中存在间谍代码。代码量大是一回
事，但是如果你是它的忠实用户，随时跟着它的版本控制系统查看代码增量的话，
加入的间谍代码是一目了然的。目前的大型自由/开源软件项目中，很多这样的忠
实用户。
wanghx
w 写道:
wanghx
mon...@gmail.com
> 我完全理解你所谈的问题，但这不是 gtalk 中文版明文通信问题的关键。
> 基于 SSL/TLS 的信道加密，就已经可以实现大部分人关心的加密通信。人们关心 gtalk 加密问题，主要是为了防止信息过滤和网络截包监视。gtalk
> 的服务器上的安全度，这不是现在问题的关键。QQ 服务器和 gtalk 服务器在用户的心目中安全信用是不同的。
>
不过从我之前的说明的那些事实来看，gtalk依然是比较安全的——只要你采用合适
的安全策略，是可以保证信息的安全传递的。
> 更完善的端到端的加密，skype, simplite, pidgin+otr 是这类。更重要的倒不是加密方案，而是木马间谍代码这类问题。比如
> tom.com skype 和 qq 都有监视通信内容的间谍代码。
>
的确，skype和qq确实存在这问题。我甚至不排除官方版本的gtalk也存在这问题。
因为官方版本的gtalk并不是自由/开源软件，里面的内容谁也不知道。不过pidgin
+otr的话就基本不会出现问题了——至少在代码层次上应该没有恶意代码存在。
> gtalk 1.0.0.105 版本的英国版如果和中文版一样是明文通信，那么不是 google 作恶。如果不同语言版本的加密处理不同，则是 google
> 配合暴政作恶的证据。这才是问题的关键，而不是什么端到端的加密技术的讨论。
>
是的。我明白你想表明的意思。我并非想证明google推出g.cn依然是在配合暴政
了。我只是想说，比较起来，QQ，MSN，和gtalk三者， gtalk还是目前比较安全
的。我不认为skype更安全，因为其协议不公开，代码不开放，除了开发者，没有
人知道它会做什么。这与它是不是p2p系统无关。
mon...@gmail.com
> 验证过了，换成英国英语版本 1.0.0.105 googletalk-setup-en-GB.exe，通信内容是明文，和中文版一样不加密。而美国英语版
> 1.0.0.104 googletalk-setup.exe 则是加密通信的。也就是从你的 gtalk 到 gtalk
> 服务器是加密的，但是服务器知道你的通信内容，且和你对话的对方是否采用加密通信是未知的，具体要看他所用的软件版本和通信方式。
>
件。过几天我会试一下。
wang_lei
91c3f19f-edw931b13-1619a674f3l mon...@gmail.com said the following on 08/26/2009 08:06 AM 写道:
>
> wanghx 写道:
> 我明白。毕竟很多人使用gtalk还是出于安全的考虑。
>
> 不过从我之前的说明的那些事实来看，gtalk依然是比较安全的——只要你采用合适
> 的安全策略，是可以保证信息的安全传递的。
> 的确，skype和qq确实存在这问题。我甚至不排除官方版本的gtalk也存在这问题。
> 因为官方版本的gtalk并不是自由/开源软件，里面的内容谁也不知道。不过pidgin
> +otr的话就基本不会出现问题了——至少在代码层次上应该没有恶意代码存在。