博客使用了椭圆曲线 TLS 证书

心血来潮把博客的证书更新了,加密算法由本来的 RSA-2048 更换为 EC-256。简单来说,HTTPS 通讯初始化的时候,需要在服务器和客户端之间交换一个 TLS 证书,用来验证服务器的身份。

由于每次 HTTPS 通讯时,都需要下载这么一个证书,它的体积在一定程度上决定服务器响应的速度。传统的基于 RSA-2048 算法的证书,有 2048 位即 256 字节大小,而新的 EC-256 算法,则只需要 32 字节。更换之后,一下子就少了 200 多字节,在网络繁忙的时候,可以有效地传输。

EC 或者 Elliptic Curve,中文译为“椭圆曲线”。EC 是一种新的非对称加密算法。EC-256 所提供的安全性相当于 RSA-3072,已经高于传统的 RSA-2048,但只需要 1/8 的体积,性价比很高。

不过博客的速度已经很快了,更换证书的性能提升应该是感受不到了 :P

如果你使用了 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 的安全性无懈可击,但是拿到工程领域就不是那么回事了。工程上出问题的机率要比学术上大很多。所以有很多事情,不能只看学术论文,还要把实施者的能力考虑进去。我在说的是什么事,大家应该都能猜到。

在 Debian 中启用 TCP BBR 算法

博客恢复之后第一件事就是升级了一下主机。现在最新的 Linux 内核是 4.9,并且带了一个新的 TCP 算法,称为 BBR (Bottleneck Bandwidth and Round-trip)。

BBR 算法由 Google 提出,原先主要用于 Google 内部网络的速度提升,现在 Google 把它提交到了 Linux 内核,所有人都可以使用了。从 Google 的报告来看,这一新的算法可以明显降低网络延迟。Youtube 全球的延迟比之前的 CUBIC 算法下降了 50% 以上。从大众的讨论来看,这一新的算法主要被用于不可告人的活动。当然,由于我用的是 Google 的主机,现在如果又用了 Google 算法,是不是会更快呢?

开启的方法如下:

1. 先升级到最新的内核(适用于 64 位的 Debian Jessie):

2. 开启 BBR

打开 /etc/sysctl.conf文件,在文件末尾添加两行:

其中第一行 default_qdisc指的是默认的 TCP 队列算法,fq 是 Google 推荐的算法,更适用于 BBR。第二行则是开启 BBR 算法。

3. 重启并验证

直接重启主机是可以的。如果不想重启的话,可以使用以下命令来加载新的配置:

然后使用下面的命令来验证 BBR 已生效:

结果会显示 BBR 加一串数字,说明 BBR 算法已启动。

4. 效果

由于我的博客已经很快了(笑),一时半会看不出什么效果。不过启用了之后心理感觉还是不错的。

收到了 StrongVPN 的汇款

一个月前提到过,StrongVPN 在八月份的时候很受欢迎,以至于我赚到了一笔四位数的佣金。

前几天,佣金到帐了,Paypal 截图如下:

话说我是不是该单独开一个栏目讲解一下网赚的经验呢(笑)

顺便再给 StrongVPN 打个广告,它家的优势是:

  • 在世界 22 个国家有 458 个 VPN 服务器;
  • 24 * 7 不间断的客户服务;
  • 最高支持 2048 位加密;
  • 7 天无条件退款;
  • 在 Windows、Mac OS、iOS、Android 上提供了应用程序可以自动配置 VPN;

还有一份详细的注册流程说明

Vultr 注册送 $50 活动

Vultr 是一家美国的主机商,提供各种类型的主机(VPS)。它家在全球 14 的地区有数据中心,包括美国西海岸和日本,对大陆用户很友好。

和其它的云计算厂商一样,Vultr 也提供了用多少算多少的计费方式,最便宜的主机只有 $0.007 每小时,换算成人民币也只有几分钱,相当合算。即使按月购买,一个月的价格是 $5,附带了 1TB 的流量

最近 Vultr 推出了注册送 $50 的活动,对于想要试用一下他们家服务的同学,这是一个很好的机会。尽管博主对其它的主机没什么需求,Google Cloud 毕竟价格高昂,Vultr 的主机更加大众化一下。

如果你想试用一下 Vultr 的主机,点这里注册吧。

DDoS 你好,DDoS 再见

前些日子佐仔的博客下线了,几天之后重新上线。过去一看,原因是主机遭受了 DDoS 攻击,随后被 ICDSoft 逐出了家门。无独有偶,坛子兄也遭受到了类似的攻击,也被 ICDSoft 列入了黑名单。

香港的主机容易受到攻击,这是不争的事实。因为香港离大陆很近,网络连接速度快,开设博客又不需要备案,于是就成了很多博客主的首选。当然博客的质量参差不齐,香港目前还相对自由,内容不受限制,以至于一些不法分子趁虚而入,发表一些反动言论,从而遭到攻击。当然我不是说上述的两位博主反动,他们只是被误伤了。虚拟主机的一台机器上好多个站点,一个站点受攻击,其它站点连带着遭殃也是正常的事。只是 ICDSoft 的做法有点让人不爽。

被 DDoS 攻击是很常见的事,前一阵子 GitHub 也被攻击过,怎么就不见 GitHub 把受攻击的 Repo 扫地出门?GitHub 当时的做法是依靠自身的硬件和运维,硬抗下了两周时间的 DDoS,最终使得攻击方自行终止,放弃攻击。

相比之下,ICDSoft 的做法很 Low。技术水平达不到,就不要出来做主机商;被攻击了不先反省自身问题,直接把责任推卸到博客主头上。不仅技术不行,道德也成问题。

写到这里,不禁想到一个段子。曾经 Google 受到过几百 G 的流量攻击,结果一点影响都没有,流量还没有直播女王登基60周年庆典的大。这个段子的真实性有待考据,不过它从一定程度上反应了 Google 网络的强壮程度。

所以呢,空间商要选高质量的,就算抗不住 DDoS,也不能随意乱踢人。当然,如果能抗得住攻击,那就更好了。另外也对玩 DDoS 的菜鸟们说一声,不要去欺负弱小的服务商了,想提升自己的水平呢,还是要找一些牛 X 的目标

在 Google Cloud 架设博客的费用

说说目前博客的费用,给想用 Google Cloud 的同学们一个参考。

Google Cloud 的计费方式和 AWS 有点不太一样,AWS 想要便宜,需要事先买一个套餐,套餐价比常规价格便宜,但必须用上个一年或三年,如果一年内终止使用,套餐的费用是不退的。之前发生过买了三年的套餐,结果 AWS 推出新机型并且降价了,导致老的套餐性能又差又不合算的局面。

而 Google Cloud 则没有这个限制,它只需要你使用一种机型达到一个月,即可以享受优惠价格,比 AWS 要灵活很多。刚搬过来的时候,进行过几次调整,导致没有用满完整的自然月,于是一直没法发这个统计,总算现在有完整一个月的纪录了。

总共使用 45.06 美元,包括三台主机,博客放在亚洲的主机,兼当 DNS 服务器,另外还有两台从属 DNS,分别在欧洲和美国地区。目前这样的配置应该超过90% 的博客了,所以新建博客的费用只会比这个少。

以下是明细,单位为美元,已减掉用满一个月带来的优惠:

  • 博客主机,总计 28.99
    • A(Small / 亚洲):17.29
    • B(Micro / 欧洲):6.11
    • C(Micro / 美国):5.59
  • 流量,总计(58.9 GB) 12.19
    • 中国地区(46 GB):10.63
    • 亚洲其它地区(5.5 GB):0.68
    • 欧洲地区(2.4 GB):0.28
    • 美国地区(5 GB):0.6
  • 硬盘,总计(30 GB)3.85
  • Google Cloud Storage,863 GB * 小时,0.03

需要指出的是,Small 主机的配置是 1.7G 内存,外加我用了 10G 的硬盘,这样的配置比大多数 VPS 是要好的,比如 Linode 和 Digital Ocean 上 2G 内存的 VPS 都要 20 美元一个月。

而这个月 Google Cloud 又进行了一次降价,降完之后应该属于超合算的云主机了。