站点启用 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 数据。

由快播的庭审说说加密解密的问题

今天是“快播”涉黄案开庭的日子,新浪网直播了庭审全过程,过程中充满了各种欢乐。我们来说说其中的一个:

且不说这位审判员对于法律是多么地无知,用户的文件无论有没有加密都属于个人隐私,能问出这样的问题显然是对隐私保护没有一丁点的认识。

接下来我们从技术的角度来说说,为什么不能解密。

加密解密实际上是纯数学的东西。如果把一个需要加密的文件看成是一串数字,比如一个文件由一串数字序列(A0, A1, A2, ..., An)构成,这个序列可以被人阅读和理解。加密的过程就是把上述 A 序列转换为(B0, B1, B2, ..., Bn),这个 B 序列是完全杂乱无章,看不懂的内容。然后解密就是加密的逆过程,把 B 序列再翻译回 A 序列。这两个转换过程中都需要大量的计算,而计算机的产生使用大规模加密解密成为可能。

加密解密的一个典型应用场景是寄信。比如小张要写一封信给小红,为了防止信件在寄送过程中被别人看到内容,小张可以把信的内容先加密,然后收小红收到信之后再解密,即可确保寄送过程中没有人可以看懂信件的内容。

加密解密的一个重要工具是密钥。密钥的本质也是一串数字序列(C0, C1, C1, ..., Cn),把它和 A 序列以某种方式混合,即可产生 B 序列。然后再把 C 序列和 B 序列以某种方式混合,即可产生 A 序列。这种方式称为对称密钥加密。常见的对称密钥加密方式是 AES,暴力破解 AES 加密需要千百万年的计算时间,因此被认为是安全的。

使用对称密钥加密的前提条件是,传递信息的双方事先要约定一个密钥,有了统一的密钥,才能顺利地加密和解密。我们在谍战剧里经常看到的,战争的一方截获对另一方的密码本,从而监听到了重要的信息。这个密码本,就是这里说的密钥。密钥需要定期更新,否则就有可能被对方暴力破解,或是以其它的方式窃取。

从谍战剧中我们可以看到,对称密钥加密的主要缺点就是,交换密钥不方便。虽然后续的通信都加密了,但是密钥的传输过程中却是公开的。密钥的传输过程成了加密解密中的薄弱环节。

那么有没有办法解决这个问题呢?当然是有的。这种方法称为非对称密钥加密

非对称密钥加密的密钥包含两部分:公钥和私钥,公钥可以公开,私钥需要保密。而非对称密钥加密是一个外人看来很玄乎的东西。先说说它的过程:小张手里有一对公钥 P 和私钥 X,小红手里有一对公钥 Q 和私钥 Y。小红先把自己的公钥 Q 告诉小张。小张使用 Q 和自己的私钥 X 把信件的内容 A 加密成 B,然后把 B 和小张自己的公钥 P 一起告诉小红。然后小红使用自己的私钥 Y 和小张的公钥 P 对加密内容 B 进行解密,即可还原出 A 来。相信看到这里多数人都已经晕了。

具体原理这是不多说,它和素数分解有关。它对于密钥的保护措施是加密的双方只需要交换公钥即可进行加密和解密,而即使公钥被第三个人知道,他也没有办法破解加密过的文本。常见的非对称密钥加密方式是 RSA,暴力破解 RSA 同样也需要千百万年。非对称密钥加密最常见的应用是 HTTPS。这下知道为什么 HTTPS 是安全的了吧。

于是这里就解答了那位审判员的疑惑,为什么不能对用户上传的文件进行解密,因为根本解不开。如果快播的用户在上传视频时使用了非对称加密,下载视频的用户在观看时解密,这个过程中快播是没有办法知道其中的内容的。聊天软件 Telegram 也使用了类似的方式进行端到端的加密,使用聊天内容就连 Telegram 自己也不知道。

和加密相关的另一个技术称为哈希(Hashing),哈希的作用是验证源文本的真实性。举个例子,小张立了一份遗嘱,他显然不需要对这份遗嘱加密,因为遗嘱最终是要公开的。而他要做的是,确保最终公布的那份遗嘱和他最初立下的是一样的。于是小张可以在立下遗嘱的时候对这份遗嘱做一个哈希,在遗嘱公开的时候,对公开的遗嘱再做一次哈希,如果两份哈希码一致,才说明遗嘱没有被改动过。当然这其中还涉及到一些哈希保密的步骤,这里不细说了,大家知道这个意思就可以了。

哈希和加密解密的一个重要区别是,哈希生成的哈希值,是没有办法解密的,就是还原不回去,只能把 A 哈希成 B,不能再从 B 推导出 A。哈希在计算机领域的一个常见用途是保存密码。比如你在某个网站上注册了一个帐号,这个帐号包含用户名和密码。而网站的管理员不希望除了你之外的其它人看到这个密码,于是网站上所保存的内容只是密码的哈希值,而不是密码本身。在你每次登录网站的时候,网站都会对你输入的密码做一次哈希,如果哈希值和网站数据库中存放的一致,则表示你输入的密码正确。而即使有人偷取了网站所保存的哈希值,也没办法还原出密码来,也就不能登录你的帐号。

现在主流的哈希算法是 SHA-2。一个常见的应用场景是两步验证

好了,说了这么多加密解密相关的东西,回过头来说说快播。我没有用过快播的软件,也不太清楚快播对色情视频的打击做到了什么程度。但从技术的角度来看,P2P 的加密内容分享是无法被解密的,这也加速了全球日益高涨的恐怖威胁。全世界的政府都在要求商业公司提供用户的解密数据,与之相对的是数学领域的加密理论已经远远把监控和破解甩在了身后。我不认为任何公司需要对技术的进步负责,科技的进步是大势所趋,而需要改进的,是那些仍处于落后状态的事物。

Go 语言中奇怪的 if 语句

上篇文章提到过 Go 语言中带有强烈的设计者的主观想法,Go 的 if 语句就是其中一例

常见的 if 语句大约是这个样子的(C++):

这样有一个问题:变量 event 定义在了 if 语句的外面,也就是说,在 if 语句之后,也可以继续使用 event 变量;而如果后续的操作中不需要 event 变量了,它实际上就造成了命名空间的污染。这并不是一个严重的问题,多数情况下不会造成任何问题,而如果一定要解决的话,在 C++ 中可以在 event 的定义之外套一层大括号来限定它的作用域。虽然代码看上去有一些奇怪,但无伤大雅。比如这样:

但是 Go 的设计者不知是出于什么原因,非要从语法上解决这个问题。于是 Go 中的 if 语句可以写成这个样子:

对,你没有看错。虽然 event 是定义在了 if 中,但它在 else 中也是可以用的。也就是说,这种写法实际上是上述的 C++ 写法的语法糖。

并不清楚 Go 的设计者添加这个语法糖的目的是什么。它仅仅是为了解决变量的作用域问题而提出,却牺牲了代码的可读性。if 语句可能会变得过长而不易阅读;在后续重构的过程中,拆分 if 语句也会变得困难。为了解决一个小问题而增加一种有问题的语法,看上去有点得不尝失。

吐槽一下 Go 语言

由于公司一直都在大力推广 Go 语言,我也有幸接触了一下。虽然 Google 内部已有三大语言(C++、Java、Python),Go 在公司内部的政治意义大于它的实际使用,但它的设计却有着很多亮点。比如 Go 自带了代码格式化工具(gofmt)和自动化测试工具(go test),这些标准化的工作在其它语言中一直都存在着多方争议,一直都不能统一,而 Go 从一开始就搞定了这些琐碎问题,让广大程序员可以把重心都放在开发新程序上,而不是争一些有的没的。

当然,这篇文章并不想表扬 Go 语言,而是要吐槽一下它的缺点。

Go 的设计者有着强烈的 Unix 背景,有一些平台依赖的东西都默认甚至是强制成 Unix 的。比如 Go 语言中有一个名为“path”的包,用来操作路径,而它强制路径分隔符为“/”,而无视 Windows 中的“\”。后来估计是开发中遇到一些问题,又做了一个叫“filepath”的包,来兼容 Windows 的使用。又比如 Go 语言中对环境变量的解析,强制环境变量的标识符为“$”,而不视 Windows 中的“%”,甚至整个标准库中都找不到对“%”的处理方法。这些基本的区别都不做处理,很难想象 Go 语言在跨平台设计中有哪些更为隐藏的坑。

这还不是主要的问题。更严重的问题是,Go 语言中有过多的“私有”特性,对使用者不公平。

先来举一个 C++ 的例子,C++ 中有一些运算符,比如加减乘除,这些运算符可以使用于 C++ 的基础类型(如 int)上。基础类型是 C++ 语言本身提供的,如果运算符只能作用于基础类型,那么 C++ 也可被视为“自私”的。然而 C++ 的设计者并没有这么做,这些运算符,不仅可以用于基础类型,也可以在自定义类型中,通过重载的方式来使用,使得 C++ 中不仅两个 int 可以相加,两个 class 的实例也可以相加。这样一来,运算符对于使用者就是公平的。

而 Go 语言中,则有着很多反例。比如它的泛型:Go 的官方说法是“我们不支持泛型”,具体原因就不深入讨论了。但是,Go 语言的自有类型 map 和 channel 却是支持泛型的。这就成了一个典型的“自私”的例子。类似的例子还有 Go 语言中的 internal 包有着特殊的作用域;Go 的官方库有着极短的包名,而第三方库通常是以“github”开头的很长一串文本。

这些“私有”特性,说明 Go 语言的设计者并没有为开发人员考虑过,自己设计得爽了,却徒增了学习曲线,不利于 Go 语言的推广。如果能把这些问题解决好,Go 还是可以成为一门不错的语言的。

在 Markdown 中设置链接由新窗口打开

尽管我对 Markdown 不是那么感冒,但工作和生活中总是难免会使用到一些,比如在向某些开源项目发 PR 的时候。于是对 Markdown 的一些小技巧也有所了解。

Markdown 中的链接语法是这样的:[文本](链接)。它相当于 HTML 中的

但众所周知,HTML 的 a 标签有一个实用的属性 target,当它的值为“_blank”的时候,浏览器会默认为这个链接打开一个新窗口,而不是在当前页面转向新页面。而 Markdown 中没有这个“_blank”选项,于是所有链接都只能在当前页面打开,有些情况会非常不方便。

在多数 Markdown 解释器中(如 GitHub Flavored Markdown),这个情况无解。如果一个 Markdown 解释器同时支持 HTML 语法,则这种情况可以通过直接写 HTML 解决。

于是我又多了一个不喜欢 Markdown 的理由。

iPhone 6s 省电设置

我把 4s 时代的省电方法用在了 6s 上面,结果是我的 iPhone 6s Plus 不充电的情况下可以正常使用至少三天。一到家就插充电线的情况就此离我远去了。

接下来介绍一下省电的经验:

关闭通知

几乎每个应用都会有通知(Notification),从应用的角度来说,它肯定希望多发一些通知来引起你的注意,以便经常打开那个应用;而从我们用户的角度来说,大多数通知是没有意义的,通知多了不仅令人烦躁,还大量地消耗电力。

关闭的方法如下:

  1. 打开“设置 -> 通知”,会看到一排应用列表;
  2. 对于不必要应用,点进去把“允许通知”关闭即可。

我只保留了一些必要功能的通知,比如短信和 Facetime,而 90% 的应用通知都被我关闭了。

仅在应用中使用位置服务

iOS 的位置服务(Location Service)有三种权限设定:永不(Never)、使用应用程序期间(While Using)、始终(Always)。由于 iOS 的伪多线程机制,一个应用在不显示的时候,实际上处于挂起状态。于是把权限设为“当使用时”可以避免位置服务一直处于开启状态,以节省电量。

设置方法:

  1. 打开“设置 -> 隐私 -> 位置服务”,会看到一排应用列表;
  2. 对于每一个应用,点进去选择“使用应用程序期间”;
  3. 如果这个应用不支持“使用应用程序期间”,我一般会设成“永不”。

关闭后台程序刷新

iOS 允许应用程序在后台挂起的同时,做一些必要的工作,比如音乐应用在后台下载歌曲等。然而并不是所有的应用都有必要在后台运行。对于那些我们并不关心的应用,大可把“后台程序刷新”给关了。

设置方法:

  1. 打开“设置 -> 通用 -> 后台程序刷新”,会看到一排应用列表;
  2. 对于大多数应用,都可以把这项功能关闭;

我只保留了一些必要的应用,比如 Google Photos(后台上传照片)、Google Calendar(刷新日程)等,90% 的应用都关闭了后台刷新。需要注意的是,这项功能对新应用是默认开启的,所以过一段时间之后,还要回来看看,把那些新安装的应用也关掉。

关闭 Siri

个人经验,Siri 除了偶尔调戏一下之外,并不会经常使用,但它启用的状态下,却一直在消耗电力。

设置方法:

  1. 打开“设置 -> 通用 -> Siri”;
  2. 把 Siri 整体关闭;

关闭 iCloud 备份

在最新 iOS 中,照片已经有了单独的一项,称为“iCloud 照片库”,而之前的“iCloud 备份”只是用来备份一些应用程序设置和数据。而我从来都没有用到过这些备份,每次换新的 iPhone 都是设置为全新的 iPhone 而不是从备份中恢复。于是这些备份所占用的空间和备份时使用的电量,对我来说是完完全全的浪费。

设置方法:

  1. 打开“设置 -> iCloud”;
  2. 找到“备份(Backup)”;
  3. 点进去把它关闭;

总结

以上这些设置可以让 iPhone 4s 在用了三年之后,还可以待机一天左右。而 iPhone 6s 的电量是 4s 的大约两倍,并且性能上有很大的提升,于是待机三天不成问题。

在德语键盘中输入 @ 符号

标准的英语键盘大家都很熟悉了,其中的“@”符号在数字“2”的上方,使用 Shift-2 按键组合即可打出。

不幸的是,某一次我把输入法改成了德语,然后我的 Macbook Pro 休眠了,唤醒之后,密码怎么输也不对。碰到这种情况,按公司的传统,我的反应是:

后来仔细想了想,大概是输入法改了的原因。只不过 Mac OS X 在输密码的阶段会锁定输入法,不能切换回英文。好吧,还好我有一个正宗的德语键盘,找一下 @ 字符在哪就可以了。德语键盘长这样:

可以看到数字“2”上面是引号而不是“@”,这就是为什么密码一直不对的原因。而德语键盘中的“@”在“Q”下方,可以通过组合键 AltGr-Q 或者 Ctrl-Alt-Q 打出,其中 AltGr 特指右手边的 Alt 键。

然后我就按了 AltGr-Q,但系统还是说密码不对。

于是,不死心的我又去查了一下德语版的 Macbook 键盘长什么样。

我去,原来苹果把“@”符号设计到了字母“L”那里……

好了,问题解决了,大家洗洗睡吧。