解决 GAppProxy Set-Cookie 和 HTTPS Cert Bugs

我自己写了一个类似 GAppProxy 的工具,支持 Python 和 PHP,有兴趣可以看这里

研究 GAppProxy 有两个原因:一、最近 Twitter 不能用,而我常用的 GAppProxy 却不支持我登录 Twitter;二、我最近在琢磨 SSL 证书的问题,正好用 GAppProxy 登录 Twitter 也有证书错误。

第一个 BUG:Set-Cookie Bug

GAPPProxy 目前对 Cookie 的处理有一些问题,主要出在对 header 中的多个 Set-Cookie 域处理错误,就会导致用户登录一些网站错误,无法获得正确的会话 Cookie。

举例,当服务器返回的 header 中有多个 Set-Cookie 域时,比如一般的 wordpress 返回的 header 中,Set-Cookie 域至少有三个:

Set-Cookie:
wordpress_776c41a2fee8d137928f3750eb1f0736=admin%7C1247298611%7C8b89cfc80161853957182ddfc481cd72;
path=/wp-content/plugins; httponly
Set-Cookie:
wordpress_776c41a2fee8d137928f3750eb1f0736=admin%7C1247298611%7C8b89cfc80161853957182ddfc481cd72;
path=/wp-admin; httponly
Set-Cookie:
wordpress_logged_in_776c41a2fee8d137928f3750eb1f0736=admin%7C1247298611%7C545dcea44d5e69aec5c1203c64bee061;
path=/; httponly

GAPPProxy 会把它作为一个串传给本地浏览器:

Set-Cookie:
wordpress_776c41a2fee8d137928f3750eb1f0736=admin%7C1247298611%7C8b89cfc80161853957182ddfc481cd72;
path=/wp-content/plugins; httponly,
wordpress_776c41a2fee8d137928f3750eb1f0736=admin%7C1247298611%7C8b89cfc80161853957182ddfc481cd72;
path=/wp-admin; httponly,
wordpress_logged_in_776c41a2fee8d137928f3750eb1f0736=admin%7C1247298611%7C545dcea44d5e69aec5c1203c64bee061;
path=/; httponly

这样本地浏览器对 Cookie 的设置就会错误。解决办法很简单,将这个长串用split(', ')切开,同样设置三个 Set-Cookie 域即可。

Update 20090710/Solrex:
有人评论说 ', ' 也是可能在 Cookie 中出现的合法字符串;那么我就另外想了一个办法,先用正则表达式替换将 ', ***=' 替换成 'n***=',再用 'n' 对字符串进行切割。由于在 Cookie 中正常出现的 ', ' 后面会首先跟着 ';' 或 ',',然后才可能出现 =,因此用 ‘, ([^,;]+=)’ 匹配就可以了。而且这次把修改放到服务器端了,原来的客户端就不需要修改了

Patch:

Index: fetchserver/fetch.py
===================================================================
--- fetchserver/fetch.py    (revision 92)
+++ fetchserver/fetch.py    (working copy)
@@ -29,6 +29,7 @@
from google.appengine.ext import webapp
from google.appengine.api import urlfetch
from google.appengine.api import urlfetch_errors
+import re
# from accesslog import logAccess

@@ -153,14 +154,12 @@
             if header.strip().lower() in self.HtohHdrs:
                 # don't forward
                 continue
-            ## there may have some problems on multi-cookie process in urlfetch.
-            #if header.lower() == 'set-cookie':
-            #    logging.info('O %s: %s' % (header, resp.headers[header]))
-            #    scs = resp.headers[header].split(',')
-            #    for sc in scs:
-            #        logging.info('N %s: %s' % (header, sc.strip()))
-            #        self.response.out.write('%s: %srn' % (header, sc.strip()))
-            #    continue
+            # NOTE 20090710/Solrex: Fix multi-cookie process problem
+            if header.lower() == 'set-cookie':
+                scs = re.sub(r', ([^,;]+=)', r'n1', resp.headers[header]).split('n')
+                for sc in scs:
+                    self.response.out.write('%s: %srn' % (header, sc.strip()))
+                continue
             # other
             self.response.out.write('%s: %srn' % (header, resp.headers[header]))
             # check Content-Type

第二个 BUG:HTTPS Cert Bug

简单地来说,GAppProxy HTTPS 连接的实现是一个欺骗本地浏览器的过程,类似于中间人攻击。它首先用 GAE 获得页面的明文,抓到本地,然后假冒 HTTPS 站点与本地浏览器通信。因此它就需要提供一个 SSL 证书,来完成 HTTPS 连接的建立。

但这就有一个问题,SSL 证书哪儿来的?目前 GAppProxy 对所有的站点都使用一个证书,而且这个证书是未经任何授权 CA 认证的证书,因此就会产生很多错误。首先,该证书中的授权机构不是可信 CA,Firefox 和 IE 中捆绑的证书中没有该 CA 的证书;其次,该证书的 CN (Common Name)与站点域名不同,不可用于站点的通信。因此可能每次都需要用户自己点击添加证书例外。

为了避免这种缺陷,我想出来的做法是——自己做 CA,正所谓做事情要专业,要骗就骗彻底点,骗得浏览器神不知鬼不觉。首先,建立 CA 的密钥,自己给自己签发一个证书作为 CA 的根证书,将该 CA 的证书安装到 Firefox 浏览器中,在运行时使用该 CA 为每个 HTTPS 连接的站点签发对应于该站点的证书。由于 Firefox 中已经安装了该 CA 的证书,那么所有该 CA 签发的证书都能够通过 Firefox 的检测了。

这个方法比较麻烦,而且需要电脑上有 openssl,对于 Linux 完全没有问题,对于 Windows 可能就有点儿困难了。所以我这里就给出个思路,具体实现就不谈了。
您可以在 http://share.solrex.org/ibuild/ 找到我修改后的代码,感兴趣的话可以下载下来看看。

关于 eYouIPB 和 CASNET

我不知道为什么在干正事的时候想写这个东西,大概也算是一种强迫症吧,想起来某件事情就总觉得有义务马上去做。那么就赶快写完吧。

这篇文章是写给有心人看的,如果您不知道 eYouIPB 和 CASNET 是什么东西,那么您可以无视以下内容。

eYouIPB 是中科院研究生院目前使用的网关登录客户端,但只能在 Windows 下使用。我用 Python 写的一个小软件 CASNET,就是一个 Linux 下的登录替代品,不过目前它也可以支持 Windows。昨天有同学发信问我有关科苑网关登录的问题,我顺便在这里做个笔记吧。

1. 有关流量统计。目前 CASNET 不支持像 eYouIPB 那样的实时的流量统计功能,因为我觉得没有必要。科苑上网是按照流量收费的,而这个流量是指网关服务器统计的流量,而不是客户端统计的流量,所以客户端的实时精确流量统计没有太大意义。

eYouIPB 带有实时的统计流量功能,但这却造成了一些问题。eYouIPB 使用 WinPcap 库做流量统计,而且这个库的版本比较低。假如系统里安装了新的 WinPcap 库,例如 Wireshark(Ethereal) 网络监听程序就会安装 WinPcap 库,那么 eYouIPB 就无法工作了。WinPcap 是一个非常强大的抓包库,而 eYouIPB 仅仅使用了其中的流量统计功能,实在很让人费解它为什么要使用 WinPcap 库并且将它的 dll 包含在自己的软件中。我想应该有更简单的办法做流量统计——如果非做不可的话。

2. 有关登录方式。科苑上网有两种登录方式:一种是 eYouIPB,使用私有的协议;一种是网页登录,使用 https 表单交互。由于 eYouIPB 协议私有,CASNET 只能模拟网页登录的方式,所以您会发现 CASNET 登录速度会比 eYouIPB 慢一点儿,因为它有一个完整的 https 安全协商和交互过程,而 eYouIPB 只需要几次简单 tcp 数据包交换就可以了。不过因为同在一个局域网内,这个速度还是在可以忍受的范围之内。

3. 有关安全性。去年我曾经研究过 eYouIPB 的协议,发现还是相对简单的。我记录的笔记已经丢失,但大概是这个样子的(应用层):“首先 eYouIPB 向服务器发起一个连接,服务器应答可以连接,然后 eYouIPB 将用户名和域发送给服务器,服务器看上去会返回一个密钥,然后 eYouIPB 使用该密钥用某种加密算法加密用户口令(或者还有其它信息)发送给服务器,服务器验证口令,回应是否可以登入。”

从该协议的实现来看,安全性有限。一个是用户可以通过不停地登入登出收集明密文对,另外反汇编 eYouIPB 看起来也不是那么困难,尤其是可以使用 Winsock 32 的 API 来定位负责加密的代码段。一旦加密算法被了解,窃听 eYouIPB 的数据包就能获得用户的口令,那么帐户就可以被窃取。所以相比而言,https 的登录方式更值得信任。

PS: 今天顺便搜索了一下,有个朋友曾经对 1.03 版本的 eYouIPB 协议进行过分析,我感觉和 2.0 版本差距不大。而且这个人完全用 C 实现了 eYouIPB 1.03 的加解密函数如果他仅仅凭逆向工程做出这个结果的话,我是相当地佩服的(因为我花了一整天的工夫也没有做出来一点儿东西)。如果当初我能看到这个结果的话,说不定就有 clue 去模拟 eYouIPB 的协议而不是使用 https 方式了,现在是懒得再去钻研这个东西了。只是不知道 2.0 是否还在使用同样的加解密函数,如果仍在使用的话,那么对有心人来说这个口令保护措施基本上算是不存在了。

4. 有关软件运行速度。这个比较主要是 Windows 平台下,CASNET 是用 Python 脚本写成的,而看起来 eYouIPB 使用 VC++ 写的,在软件的大小和运行速度上 eYouIPB 要显然优于 CASNET。由于 CASNET 的 Windows GUI 版需要额外的 GTK 运行时库和 Python 库支持,大概会加载到内存中 16M 左右的数据,不过这些东西运行时真正用到的不多,所以有些部分除了初始化时,其它时候很可能是驻留在交换区中,所以还是可以接受的。

在 Linux 平台下,因为 GTK 和 Python 库是被非常广泛使用的,所以 CASNET 并不需要额外占用很多内存。

之所以会发布 Windows 版,是因为相比 eYouIPB 而言,Wireshark 对我更重要,所以我无法使用 eYouIPB,而又讨厌网页登录时每次都要选择下拉菜单。再加上顺便看看 PyGtk 在 Windows 下的表现如何。但比较讽刺的是,Windows GUI 版的 CASNET 下载量要超过其它版本加一起的下载量,看来它的存在还是对某些用户有一些帮助。

5. 有关软件功能。eYouIPB 的功能已经被锁定了很多年,但是 CASNET 一直在根据用户的需求增加或者删减某些功能,例如余额不足提醒,断线自动重连,一键切换登录模式等。还有一个未发布的功能是关机自动下线。这是一个我一直想实现的功能,因为当用户关机忘记离线时,恰好分配到原 IP 的用户就可以使用该帐号,造成流量被窃取。这个功能在 Linux 版本上已经基本实现,但是 Windows 版本仍然没有找到可用的方法实现。

从安全的角度理解——为什么要使用 Google 的服务?

我很喜欢 Google 的一些服务 Gmail, Reader, Documents等等,而且我也一直大力倡导周围的人使用 Google 的服务。在我看到一些人仍在使用 163, sina 的信箱,抓虾的在线订阅器的时候,我不禁为他们通信的安全性担心。为什么使用 Google 的服务?一个很重要的原因是:因为它更安全。

目录:

1. 得到抓虾用户名密码的例子
2. 嗅探和可嗅探网络
3. 为什么 Google 更安全?
4. 为什么 163, sina, 抓虾 不安全?
5. 如何使用 Google 提供的安全服务?
6. 使用 Google 提供的安全服务的额外好处

1. 得到抓虾用户名密码的例子

首先,来看一个截图,看看国内某著名在线订阅器网站抓虾网对用户密码的保护有多脆弱:

Wireshark_Zhuaxia

请大家注意截图的最下方,能否看到这一行字:
email=solrex%40gmail.com&password=testtest&persistentCookie=true
solrex@gmail.com 是我在抓虾的注册帐号,而后面的 password 大家应该知道是什么东西吧!(不用试我的帐户,我的密码已经改了。)

有人会好奇这张截图怎么得到的,其实这是我在自己的电脑上用 Wireshark(一款著名的网络数据包分析软件,其前身是 Ethereal) 对通过我网卡的到抓虾网数据包进行监控的截图。Wireshark 实际上就是一款嗅探器,它能记录经过指定网络接口的所有数据包并进行分析。

2. 嗅探和可嗅探网络

为了解释如何才能得到上面的数据包,首先要介绍一下网络嗅探的原理:

嗅探,是一种黑客的窃听手段,一般是指使用嗅探器对数据流的数据截获。由以太网的知识我们知道,在以太网的冲突域中,每台主机的网卡都能接触到所有的数据包,如果数据包的目的地址是自己,网卡就接收数据包,并将包的内容向上层传递;如果数据包的目的地址不是自己,就将该包丢弃。那么如果网卡接收所有的数据包并对其进行分析呢?这就是所谓的“混杂模式”,将网卡设置为混杂模式后,就可以接收所有包,进而对同一网络中的其它主机的通信内容进行监听,这就是 Wireshark 进行嗅探的原理。

需要说明的一点是,在当前的网络下,直接进行嗅探并没有那么容易。上面所说的情况,只在以太网的冲突域中才能实现,而当前交换机的广泛使用,将冲突域限制到交换机和主机两点之间,除了自己没有其它主机,当然也无法直接对其它主机的通信内容进行监听。如果在交换网络下达到嗅探的目的,必须通过其它办法,比如 ARP 欺骗,这超出了本文的讨论范围,就不予介绍了。

虽然在交换网络下无法对其它主机进行直接嗅探,但是我们无法保证在我们的数据包经过的防火墙或者网关时候不会被监听。就比如在实验室的网络环境下,实验室的管理员在网络出口的防火墙处对数据包进行分析是易如反掌的事情。

所以我们总结一下,用户通信的数据包被监听可能发生在几种情形下:一、共享网络,网络用户通过集线器连接到网络;二、交换网络的结点不可信任,比如公司网络的出口防火墙管理员不可信;三、缺乏安全机制的无线网络,比如学校为学生提供的无线网络连接(用 WEP 加密传输的网络可以认为是缺乏安全机制);四、有ARP欺骗的交换网络。

由于很多网站的登录 session 是使用的 http 协议,在此协议下,用户名和密码都是通过明文传输的(抓虾和 sina 就是一个例子),所以当用户处在上述的网络环境下时,很有可能数据包被别人监听到。而数据包一旦被监听和分析,得到用户的信息易如反掌,南京大学小百合 BBS 最近的一篇文章:你还敢在教室中享受无线吗? ,就是一个很生动的例子。

3. 为什么 Google 更安全?

首先,因为 Google 采用了 https 协议来处理用户登录请求。https(Hypertext Transfer Protocol over Secure Socket Layer) 协议是指加强安全的 http 协议,正如它名字所示,它采用 SSL 来保证数据的加密传输。举个很有证明力的事实,如果你有任何一个银行的网上银行帐号,请打开你的网银登录窗口,查看上面的地址栏内容开头是不是:https://xxx.xxx.com/xxxx 。没有任何一家银行采用 http 协议处理网银登录请求,这说明了什么?http 协议不安全。

其次,因为 Google 使用可选的 https 协议来提供内容传输服务。虽然 Google 在其任何服务的登录请求处理中都是使用 https 协议,但是在认证完用户之后,和 Google 服务器的连接就转回到了 http 协议。这样虽然 Google 的用户名和密码不能被窃听到了,可服务的内容,比如 Gmail 邮件的邮件内容就会被恶意用户窃听到。那么如何使整个通信的内容都受到保护呢,就需要使用 Google 提供的可选 https 服务,只需要在你的浏览器地址栏内容的最前面 http:// 换成 https:// 即可。

4. 为什么 163, sina, 抓虾 不安全?

sina 和 抓虾 没有提供任何的帐户信息和内容的安全传输功能,所以在课堂上演示嗅探器工作方式的时候,演示者一般都会首先拿 sina 开刀,原因很简单,它是个大网站。

163 呢,比前面两个好一点儿,它提供了可选的帐户信息的加密传输功能,就是在登录 163 信箱的时候,在登录框下面有一个“增强安全性”的选项,如果勾选了增强安全性选项,163 就会用 https 来处理用户的登录请求。但是 163 仍然没有提供对用户内容的加密传输功能,即 163 的所有邮件在网络上都是明文传输

5. 如何使用 Google 提供的安全服务?

如果用户希望自己的帐户信息和传输内容都受到保护的话,那么就应该使用 Google 提供的 https 连接登录 Google 服务。比如Gmail 的 https 入口是:https://mail.google.com/ ,Google Reader 的 https 入口是:https://www.google.com/reader/ 。在 Google 其它的服务中,用户也可以简单地通过将地址栏的 http:// 换成 https:// 来选择使用安全传输。

6. 使用 Google 提供的安全服务的额外好处

使用安全的加密传输能保证自己传输的信息不被别人获取,这是显而易见的好处,但是使用 Google 的安全服务还有一点额外好处:避免自己的网络访问被关键词过滤。

有过访问敏感站点经验的同志可能都知道,如果网页中包含某些关键词,连接往往会被重置。就比如用户使用 Google Reader 订阅了某个激进的博客的RSS FEED,如果使用传统的 http 连接,当文章中包含敏感关键词时,Google Reader 就会与服务器断开连接。如果使用加密传输的话,传输内容就避免了被关键词过滤,就不会发生类似连接被重置的情况。