如果你使用了 CloudFlare,赶紧改密码

CloudFlare 前几天出了一个严重的 bug,会导致经过它的流量都有一定机率泄漏。这个问题很严重,如果你直接或间接使用 CloudFlare 的服务,赶紧修改相关密码,包括重新配置两步验证

Bug 描述

CloudFlare 提供了一个功能,可以重写它缓存的内容,比如压缩 HTML 之类。其中一个用于重写的工具有一个 bug,不能正确处理某些特殊构造的 HTML 内容。在处理那些内容的时候,会错误地把一些随机内存中的内容输出。这些随机内容,包含了 HTTPS 加密的密钥、cookie 等各种非常机密的东西。

这里并不是说,如果你访问的网站,没有输出特殊格式的内容,就不会受影响。CloudFlare 通常在一台主机上分发多个网站的数据,只要同一台主机上出现了特殊的文件,你访问的网站就可能会受影响。

由于 CloudFlare 提供的内容多数是公开的,可以自由访问的。于是这些机密信息有可能已经被其它人访问到了,且已经追踪不到了。更严重的是,有一些搜索引擎可能记下了这些内容,还可供他人随时查询。

事件经过

上周五(2月17日),一个 Google 的工程师在测试某个功能的时候,意外发现了 Google 的爬虫抓到了一些奇怪的内容,看上去不像是正常的网站内容。追根溯源,发现了这些内容来自 CloudFlare,于是立即通知 CloudFlare 的安全部门。CloudFlare 也没闲着,在周末组织人力修 bug,到 21 日就完全修复了。

Google 和 CloudFlare 都发了文章来说明具体的问题:CloudFlareGoogle

CloudFlare 声称这个 bug 最早可能是在 2016 年 9 月 22 日引入的。代码中的 bug 可能已经存在了很长很长时间了,而 CloudFlare 去年推出了一项新功能,这个新功能依赖了出 bug 的代码,才把问题暴露了出来。当然,不管问题出了多久,鉴于 CloudFlare 那么大的访问量,这些机密信息可能已经泄漏得一塌糊涂了。

Google 方面说会在 90 天之后公布 bug 的细节,但是 CloudFlare 的文章里已经全说出来了 -_-

后续补救

已经有人开始收集所有使用 CloudFlare 的网站,并做成一个列表:List of Sites possibly affected by Cloudflare's #Cloudbleed HTTPS Traffic Leak。这个列表非常长,要找到自己用的服务也是需要点时间。

另外有评论说,一些 iOS 应用也受到影响,包括 Dropbox。

对于正在使用的服务,你需要做的事情:

  • 修改密码。
  • 如果开启了两步验证,需要重置两步验证,即关闭再打开。
  • 如果你使用了第三方验证,比如用 Google 的帐号登录第三方网站,也要重新做一遍验证。
  • 任何上传到 CloudFlare 上的 TLS 证书,需要重新签发。

总结

有一个共识是 HTTPS 是安全,使用 HTTPS 传输的流量,不会被第三方破解。CloudFlare 免费提供了 TLS 证书,几乎所有使用 CloudFlare 的网站,都开启了 HTTPS。并且 CloudFlare 还提供了 HTTPS 回源的选项,就是整个 HTTP 访问,都经过加密了。就在大家都认为 CloudFlare 非常安全的时候,偏偏出了这么个事情,继 Heatbleed 之后再出一次严重的 HTTPS 相关的安全性问题。

不由感慨一下,学术界反复论证了 HTTPS 的安全性无懈可击,但是拿到工程领域就不是那么回事了。工程上出问题的机率要比学术上大很多。所以有很多事情,不能只看学术论文,还要把实施者的能力考虑进去。我在说的是什么事,大家应该都能猜到。

ZeroNet 将会成为下一个失败品

ZeroNet 最近很流行,特别是在中文用户群中。ZeroNet 是一种分布式的互联网,它不像传统互联网那像需要一个一个物理的服务器来架设网站,而是每一个用户都可以作为服务器,储存一些数据并且分发给其他用户。具体的介绍不多说了,一搜一大堆,就来说说为什么它一定会失败。

我大概在 2001 左右第一次接触到网络,从那时候开始,就不断有新闻提到分布式计算,或者用现在流行的词来说,“去中心化”的系统。而随着时间的推移,这些系统没有一个成功的。

印象中最早的一个是寻找外星生命的项目 SETI@home,这个项目目前还活着,并且是已知的所有分布式计算项目中最活跃的一个。据今年一月份的统计,SETI@home 有超过 500 万名活跃用户。这个数字看上去很多了,但是呢,微信的每日活跃用户也超过了一亿。也就是说,每 100 名微信用户才有一个参与的,你的好友中可能都没有一个人听说过这个项目。

当然,分布式项目中也有参与人数多的,比如比特币,2013 年火暴的时候妇孺皆知。但是呢,今年一月份比特币核心开发者宣称比特币失败。而最近一次的炒作中,90% 以上的交易量发生在中国的比特币市场,足以证明一个“分布式”项目的失败。

ZeroNet 是最近一个分布式的尝试,但它也逃脱不了失败的命运。

原因很简单,没有商业公司支持。之前提到过,没有商业公司支持的项目,不可能胜过一个有商业背景的项目。而一个商业项目,没有必要完全去中心化。

或许你会不同意,看,BitTorrent 项目就活得很好,大家都在用 BT 下载,而它本身也是由一家同名的公司支持的。对,BT 一个非常流行的技术,但是,你听说过迅雷离线下载么?虽然现在下载依然依赖 BT 种子,但一般我的做法是把种子下载下来,传到迅雷上去,然后再通过迅雷离线下载下来。迅雷的服务器提供了比 BT 节点快得多的速度,完全没有必要使用纯粹的 P2P 下载。我相信大多数网友(至少是中国网友)都是这样做的。对 P2P 特性的依赖已不复存在。

不要提 Tor,Tor 并不是分布式项目。尽管 Tor 有自己的暗网(Darknet),暗网中的每一个网站和互联网的网站是一样的,都是依赖于一台(或几台)中心服务器,没有分布式的特性。

回过来说说 ZeroNet。ZeroNet 的愿景是发展出一套和互联网平行,完全分布式的网站系统。这个系统中每个网站都分散在各个网友的电脑中,只要有网友在线,网站就永不下线。

然而,这个系统有一个致命的问题:成本。目前 ZeroNet 的存储策略是这样的,当你访问一个网站的时候,就是把这个网站的所有内容下载下来,然后把这些内容重新分享给新用户。从冗余的角度来说,一个网站有多少用户,就存在多少份数据冗余。当然等到 ZeroNet 发展壮大了,必然不会每人都存一份。我们就假设冗余量是 1000,这个数字其实很保守了,考虑到用户的平均在线时间、地域分布等,要保证良好的访问速度,实际的数字肯定会比这个高。然后我们来看一下互联网的总量是多少。有消息说,Google 一家的数据量是 5EB,就是 50 亿 GB。而互联网网民总数目前是 30 亿左右。以 1000 冗余量存下 Google 所有的数据,需要平均每个人 50 / 30 * 1000 约为 1000 GB 也就是 1 TB 的硬盘。现在一个 1TB 的硬盘售价大约是 50 美元(民用硬盘的价格,商用的更贵),30 亿人人手一个,总价值约为 1500 亿美元。就算一块硬盘的平均寿命是五年,那么一年的平均费用就是 300 亿美元。

作为一家商业公司,Google 花 300 亿来运行它的数据中心,自然是一点问题都没有;然而对于一个非赢利项目,它能用什么方式说服全世界的网民帮他支付这个帐单,我很好奇。实际上,中心式存储的成本反而低,Google 一年花在数据中心上的钱大约是 120 亿美元

如果存不下这么多内容,ZeroNet 就发展不出那么大的规模,没有那么大的规模,如何吸引用户使用。想想现在的潮流,视频、直播、VR,哪一个不需要大容量的存储。没有这些日常所需的娱乐内容,ZeroNet 的发展方向只会像暗网一样,成为法外之地,大量不入流、违法、无聊的内容,久而久之,就没有用户了。

通过 Varnish 使 WordPress 静态化

WordPress 常常被人诟病说加载速度慢,主要原因是每一次打开页面都会查询数据库,即使每次查询的结果都是一样的。WordPress 原生不支持缓存,但可以通过插件支持,比如 Super Cache。我用过一段时间 Super Cache,它本身是一个很好的插件,但协作性不强。它只能加载 WordPress 原生的内容,而我需要的是缓存经过 PageSpeed 优化过的内容,从而达到完全静态化的效果。

曾经有一段时间 KeyCDN 的表现不理想,而 Google CDN 还没有开放,我就自己搭了几台缓存服务器,来缓解源站的压力。这几台缓存服务器是通过 Varnish 实现的。当然用 Nginx 也可以,但是 Nginx 的缓存失效(Purge)功能是收费的,而且部分平台上还是自己编译。于是我选了 Varnish。

Varnish 可以做到的事情

  • 根据 URL(或其它参数)的不同来选择不同的缓存策略;
  • 修改 HTTP 请求和响应的头部内容;
  • 设定缓存时间,时间到了自动失效;
  • 可以通过一个特殊的 HTTP 请求来让一个(或一些)缓存立即失效;

好,接下来就开始配置服务器了。

安装 Varnish

以 Debian 为例,最新的 Varnish 版本是 4.0:

配置 Varnish

先创建一个新的配置文件,比如 /etc/varnish/leonax.vcl,内容如下。其中比较重要的就是三部分:vcl_recv、vcl_hash、vcl_backend_response,可以根据自己的实际情况来调整。必要的注释已经附在相应的代码旁边了。

然后来检查一下配置文件写得对不对。如果配置正确,这段命令会输出一大段处理过的代码;如果有问题,则会输出具体的错误信息。

接着,在 /etc/varnish/default.vcl 文件中,可以找到如下一段内容:

需要把 -f 的值修改为刚才创建的配置文件地址。

重启 Varnish

配置 WordPress

WordPress 的页面需要刷新的情况,无非有三种:新文章、新评论和配置修改。配置的更改一般频繁,我的做法是重新配置之后,手动重启一遍 Varnish,这样最干净。而新评论的情况,刚才在 Varnish 的配置文件中已经处理了。于是我们现在来处理一下新文章的情况。

以下代码需要写在 WordPress 中,比如 functions.php:

收工

做完以上这些,你的站点就可以达到像本站一些的加载速度啦。

Google 对新品牌的迷恋

品牌效应,有时候比产品的质量本身更重要。品牌常常给人带来一些心理暗示,比如 iPhone 总是高大上的,而安卓就是烂大街的地摊货,尽管 iPhone 也有低端产品,安卓也有旗舰。当一个牌子做坍了之后,更换一个新品牌可能会有意想不到的改观。比如微软在 2009 年的时候把 Live 品牌强行换成了 Bing,虽然换汤不换药,但市场占有率从最初的不到 10% 到现在稳稳站上 20%,Bing 的品牌效应功不可没。

有成功的案例,自然也有失败的案例,比如 Google 在社交领域的数次尝试,Orkut、Google Buzz、Google Friend Connect、Google Wave 和最终的 Google Plus,没有一个成功的。而 Google 在聊天工具方面,也有着同样的困境。

最初的一款产品叫 Google Talk,简称 GTalk。一开始的想法很宏大,兼容 XMPP 协议,可以和其它的聊天工具互通。做了几年之后发现没什么起色,于是扔掉了 XMPP 协议,并且改名为 Hangouts,开始自己和自己玩。

Hangouts 做得很大,它兼并了 Google Voice 可以像普通手机一样打电话,在 Android 手机上还成为了默认的短信应用,更不用说在 Google+ 和 Gmail 中的集成了。几乎任何地方任何时候,想用 Hangouts 的时候就可以用到。

不知哪根筋抽住了,Google 后来又推出一个短信应用叫作“Messenger”,这是一个 Android 手机独享的应用,也可以发短信,打电话,群聊 -_- 在手机上和 Hangouts 除了图标不同之外几乎一模一样。不用说 Android 的用户了,就连公司员工,看到这个消息的时候也是一脸懵逼。

事情还没有结束,上周的 Google I/O 大会上,通信部门的老板(对,我们还成立了一个专门的通信部门)激动地宣布,我们又做了两款应用,Allo 和 Duo,一款用来发短信,一款用来打电话……好吧,Google 自家的聊天应用快占到一屏了。

如一开始所说,不同的品牌可以带来不同的客户群。比如 QQ 和微信,在 QQ 越来越臃肿,自己都不堪重负地出了 QQ 精简版的时候,腾讯果断抛出了微信。最初也有很多人不理解,但事后被证明微信是一个成功的典范。究其原因,微信最初主打的精简,速度快(当然现在也不精简了,大概可以改名为巨信),并且当时还有大量的 MSN 用户不屑与非主流为伍,不肯入 QQ 的门,微信正是看准了这部分用户群,站稳了立足之地。

但是 Hangouts 不一样,虽然它也是一个大而全的应用,但终究没有跳出聊天工具的范畴,你不能用 Hangouts 购物,也不能用它来看朋友的时间线。如果这些基本功能都要细分,那我们的手机上至少得有几百个应用,才能满足日常所需。

现在好了,Google 有了四个聊天应用(算上新出的 Space 的话有五个),正好占满了手机屏幕最下面的快速启动栏,视觉效果很震撼,真要用的时候还得想半天,到底开哪一个。

当然对于墙内的用户来说,这些都不是个事,这些应用根本不存在。就连 Hangouts 现在都没在中国区上架,更别说其它的应用了。眼不见为净,你们爱怎么玩就怎么玩吧,我们继续用微信。

Google Cloud CDN

Google 终于推出了自己的 CDN 服务了。去年 12 月份发布了 Alpha 版本,只接受申请试用;而这个月正式升级为 Beta,大伙都可以用了。于是我就又做了一回小白鼠。

之前一直在用 KeyCDN,但是 KeyCDN 的一个弱点是它依然使用 CNAME 来转发流量,而 CNAME 很容易被屏蔽。而 Google 的 CDN 用的是 AnyCast,只需要解析一次 DNS 即可访问,这可比 CNAME 要强壮多了。

除此之外,CDN 的抓取走的是 Google 的内部网络。这个网络有多快呢?据 Google 博客介绍,单机的网速可以达到 10Gb/s 以上。这样的 CDN 性能要远好于任何外部的 CDN。

于是我毫不犹豫地切换了过来。有兴趣的朋友可以对本站测个速。

吐槽一下阿里巴巴

我一直的对阿里系的东西不太感冒,除了支付宝一直在用之外(在国内的时候还会用用淘宝和天猫),其它的服务几乎没什么涉及。没什么原因,只是这家公司看上去很土。

阿里的员工都使用“花名”

大概是因为马云喜欢武侠小说,阿里的员工每人都要取一个“花名”,比如马云本人的花名是“风清扬”。每个新员工在入职的时候就要取好花名,且不能和已有的花名重复。一开始还好,毕竟各类武侠小说一大堆,随便就能挑一个像样的。而现在就不行了,阿里集团已经拥有了超过 35000 名员工,好听的名字早就没了。花名之难取,以至于坊间已经有了帮忙取花名的在线服务。

如果说取一个花名只是为了找人方便,那无可厚非。很多公司都有类似的设定,比如在 Google 这个叫做 LDAP,就是一个不重复的 ID,用于邮箱和各种内部服务的识别。比如我的公司邮箱是 ,就是直接用了我的名字,如果愿意的话也可以改成 abc 或者 xyz,只要没有人用过。

但是阿里却不一样,马云带头使用了一个小说里的名字,而且这个小说人物还是一个大侠。我不是那么喜欢武侠小说,但是也可以想象一个风清扬的粉丝进了阿里之后,看到一个长着奇形怪状脸的风清扬,大概会几天都吃不下饭吧。

阿里的产品名都很土

阿里巴巴旗下除了淘宝和支付宝之外,几乎就没有哪个产品的名字是恰当的。阿里巴巴这个名字本身和贸易并没有直接关系,反而像是骗钱的(详见《阿里巴巴与四十大盗》)。当然亚马逊和贸易也没什么关系,公司名字都是随便起的,这个就不提了。

然后阿里旗下的其它产品,槽点就多了。比如天猫,简直就是 TMall (Taobao Mall) 的无脑汉化版。还有“阿里妈妈”,不进到主页完全想象不到这会是一个什么产品。其它的小产品暂且不说(比如“咻一咻”),最近一个值得吐槽的是“钉钉”。这个名字取得真是前无古人后无来者。想象一下阿里客服的电话回访:

客服:请问,您在使用 ding ding 吗?
我:额,现在没有在用,但是每天都会用的。
客服:那每天使用几次呢?
我:大概一两个小时一次吧。
客服:每次用多少时间呢?
我:大概几十秒钟,有时候晚上一下子就要用几小时。
客服:啊?您的业务真繁忙。
我:也不是啦,只是回归正常生活而已。

不理解的同学可以搜索一下“丁丁”。

先说这么多,现在是一个看脸的年代,阿里就是一个看上去很土的公司。

站点启用 Certificate Transparency

之前一直都以为 Certificate Transparency 这个东东是给 EV 用的,没想到今天看了篇文章,说是个人站点也可以用。于是就去申请了一下。

先简单说说 SSL 证书的安全性。SSL 的机制是一个简单的信任链关系,浏览器并不能区分两个受信任的 CA 对同一域名签发的证书。比如本站的证书是由 DigiCert 签发的,如果另一个 CA 有意或无意也签发了一个对于 leonax.net 的证书,浏览器在访问网站的时候并不知道哪个证书是“真的”,哪个是“假的”。于是如果有两个网站,使用了不同 CA 签发的证书,且都说自己是 leonax.net,那么浏览器都会显示出“安全”的图标。现在 SSL 证书泛滥,部分 CA 为了降低证书申请的门槛,并没有做到严格的域名审核步骤,导致一些恶意分子有机可趁,伪造证书来骗取用户的信任。

简单来说 Certificate Transparency 是一个用于增强 SSL 证书安全性的东西,它可以确保 CA (Certification Authority) 不乱发证书。CT 的做法是通过一个第三方的验证机制,来判断证书的改动有没有出现异常。比如上述情况,会有两个 CA 同时向验证服务器提交信息,或是一个提交了,浏览器却收到了另一个的证书,这样便可以区分出“真假证书”了。

本站的证书是在 DigiCert 申请的。DigiCert 对 Certificate Transparency 的介绍可以看这里。实际上它废话了一堆,只是告诉你要去联系客服开启 CT 即可。于是我就去找了客服,十分钟搞定,当中还绕来绕去说了一些废话,可能是因为美国当地时间是夜里,客服不太清醒的缘故。不过事情也不复杂,很快客服就给我重新签发了证书。拿到新的证书之后,再上传到网站服务器即可。

开启了 CT 之后,在 Chrome 的网站信息中就可以看到类似上图的字样。说是网站已提供有效的 Certificate Transparency 数据。