Skype登录证书被劫持

上月在Skype的网页上登录，发现了一个非常值得警惕的现象，在https://login.skype.com页面，Chrome提示如下警告：

这表明所浏览网站的SSL证书有问题。

浏览器警告证书有问题的情况并不罕见，多数情况是因为证书不是由所用浏览器认可的权威证书颁发机构颁发的。比如Savannah使用的是CACert颁发的证书，而Firefox之类的浏览器没有内置CACert作为权威证书颁发机构，所以打开会有警告，但是据说Debian下的Iceweasel含了CACert作为CA。还有清华大学的校园网用户登录页面，一直在用一个2003年就过期了的无效证书。在试图下载微软Office 2010试用版的时候，我还头回碰到网页证书被颁发机构召回的情况。

但是Skype的安全登录页面出现问题，那得警惕了。我点击Chrome地址栏左边的红色骷髅，打开了网页的证书，发现是个叫bb-in.com的网站自颁发的证书，这显然不是个CA。另外，证书的授予对象是他们网站，而不是login.skype.com。

此时，我没有登录。当我用OpenVPN翻墙后再打开这个页面，没有安全警告，证书也是可信任的：

可惜当时没有对假冒的证书抓图，第二天就去出差了。等出差回来，再试验发现又没有这个问题了。

Skype安全登录的证书变成一个莫名的证书，但是用了VPN翻墙就好了。是中间有人故意作梗想偷窃用户隐私，还是仅仅是技术错误，我现在还没有足够的证据来分析。但是，这件事件让我进一步感到，在中国上网有着这么多的陷阱，让人防不胜防。对于刚刚上网的无知初级网民，他们何时才能知道这些陷阱呢？

顺便友情提醒，在国内上skype.com会自动跳转到tom.skype.com，上面提供的Skype是接受中国监控的，这一点Skype公司本身也承认的，所以千万不要去下载上面的Skype。要下载的话，翻墙后再上，就不会被跳转了。
------------------------------------
即兴送上腾迅公司的Gmail钓鱼页面：

撞墙

以前好好设置的OpenVPN，能建立VPN，但是死活无法转发包，最近不知怎么却可以了。我开始试用全局VPN下的翻墙。照旧用常见的墙外网站测试，发现三个最知名的网站：twitter.com，facebook.com和youtube.com用OpenVPN竟然翻不过去，连接很长一段时间之后显示连接超时。其它测试过的有blogger.com，blogspot.com，bbc.co.uk/chinese和foursquare.com等，都可以成功翻越。但是，如果用更加简单的SSH Tunnel代理方式翻墙，那么上面所述的所有网站都可以翻越。

后来发现在本地进行DNS查询，twitter, facebook和youtube的IP地址每次都是不一样的，系统返回一个随机的值。但是用可信的DNS服务器，或者直接从国外的VPS上查询，才会返回正确的值。

我的ISP是北京联通的小区宽带。用系统分配的DNS服务器查询结果：

tux@Neverland:~/Desktop$ dig +nocmd +nocomments twitter.com
;twitter.com.            IN    A
twitter.com.        35888    IN    A    93.46.8.89
;; Query time: 493 msec
;; SERVER: 202.106.46.151#53(202.106.46.151)
;; WHEN: Tue Aug 17 23:22:53 2010
;; MSG SIZE  rcvd: 45

tux@Neverland:~/Desktop$ dig +nocmd +nocomments facebook.com
;facebook.com.            IN    A
facebook.com.        300    IN    A    59.24.3.173
;; Query time: 496 msec
;; SERVER: 202.106.46.151#53(202.106.46.151)
;; WHEN: Tue Aug 17 23:22:54 2010
;; MSG SIZE  rcvd: 46

tux@Neverland:~/Desktop$ dig +nocmd +nocomments youtube.com
;youtube.com.            IN    A
youtube.com.        180    IN    A    37.61.54.158
;; Query time: 503 msec
;; SERVER: 202.106.46.151#53(202.106.46.151)
;; WHEN: Tue Aug 17 23:23:51 2010
;; MSG SIZE  rcvd: 45

上面的结果，重复查询每次都不一样， 而且有的IP会在不同的网址查询结果中出现，facebook.com和youtube.com就出现过同一个结果37.61.54.158。但有时候又会返回正确的IP，这大概是GFW的策略，随机出现随机的错误IP。很明显这些域名遭遇了所谓的DNS污染。如果我们用可信的DNS服务器8.8.8.8来查询，得到正确的结果，就可以更加确凿无疑地证明受到了DNS污染。

tux@Neverland:~/Desktop$ dig @8.8.8.8 +nocmd +nocomments twitter.com
;twitter.com.            IN    A
twitter.com.        8    IN    A    128.242.240.52
twitter.com.        8    IN    A    168.143.162.100
twitter.com.        8    IN    A    128.242.240.116
;; Query time: 277 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Aug 17 23:28:49 2010
;; MSG SIZE  rcvd: 77


tux@Neverland:~/Desktop$ dig @8.8.8.8 +nocmd +nocomments facebook.com
;facebook.com.            IN    A
facebook.com.        441    IN    A    69.63.189.11
facebook.com.        441    IN    A    69.63.181.12
facebook.com.        441    IN    A    69.63.181.11
facebook.com.        441    IN    A    69.63.189.16
;; Query time: 271 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Aug 17 23:31:21 2010
;; MSG SIZE  rcvd: 94


tux@Neverland:~/Desktop$ dig @8.8.8.8 +nocmd +nocomments youtube.com
;youtube.com.            IN    A
youtube.com.        140    IN    A    74.125.127.93
youtube.com.        140    IN    A    74.125.95.93
;; Query time: 300 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Aug 17 23:31:25 2010
;; MSG SIZE  rcvd: 61

如果没有受到DNS污染，那么即使是被GFW盾的网站，国内外的解析结果也没有什么不同。

tux@Neverland:~/Desktop$ dig +nocmd +nocomments foursquare.com
;foursquare.com.            IN    A
foursquare.com.        3014    IN    A    184.73.159.65
;; Query time: 521 msec
;; SERVER: 202.106.46.151#53(202.106.46.151)
;; WHEN: Tue Aug 17 23:33:38 2010
;; MSG SIZE  rcvd: 48


tux@Neverland:~/Desktop$ dig @8.8.8.8 +nocmd +nocomments foursquare.com
;foursquare.com.            IN    A
foursquare.com.        1409    IN    A    184.73.159.65
;; Query time: 277 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Aug 17 23:33:43 2010
;; MSG SIZE  rcvd: 48

问题的解决也简单，就是把/etc/resolv.conf里面的DNS换成可信的。OpenVPN应该支持DNS推送的功能，这样就可以自动解决这个问题，待我后续再研究。另外，用SSH Tunnel代理翻墙就不会出现上述的问题，这至少证明了比起用OpenVPN，用SSH Tunnel代理翻墙并不是那么弱。