Security

📜 历史文件已不具备现实意义

我认为不再需要收集更多数据了。

这个 blog 的首页底部增加了两个图，用来测试访客是否启用了 DNSsec 验证。这项服务是由 Matthäus Wander 和 Torben Weis 提供的，点击这个连接可以检查自己的 DNS 缓存服务器是否会进行 DNSsec 验证。如果没有，可以参考我的这张 作弊条 来自行配置。

今天上午，我和现任 FreeBSD 安全长官 Simon 完成了一次 PGP 密钥的转移，这里记一下过程。

由于这个密钥用于签署安全公告和声明等等，因此非常重要。发送方对于密钥做了三重加密：第一重是 GnuPG 本身的密钥密码；第二重是 AES；第三重是我本人的 PGP 公钥。加密后的结果放到了一台可信的中转服务器上，然后以安全方式取走；用我的 PGP 密钥解密之后，通过两个不同的渠道分别发送 AES 密钥；最后一步的密码采用加密方式发给我，我在解密成功之后，修改密码，并销毁全部中间文件。

今天在邮件列表里看到 John Nagle （就是发明 TCP Nagle 算法的 那个 John Nagle）提到希望 OpenSSL 提供一些帮助自动检测中间人攻击的 方法。简单地说，因为中间人攻击会改变双方看到的加密流（密钥变了），因此，如果上层协议包含了加密流的某些特征，攻击者想要实施中间人攻击的成本就会大大增加。他同时举了一个例子，一种早期的加密电话会在话机上显示从密文开始的部分计算的两位数字，而通话双方则通过通话来确认数字相同，这样，中间人攻击的实施者就必须解析语音并替换掉相关的字词来避免被发现。

简单的例子是，比如准备发出 HTML/XML 之前，首先发出它们在加密之后的密文的 hash。攻击者如果简单地截获并重新加密文档，则攻击会被立即发现；如果缓冲并重新计算结果，必然会引入延迟；如果事先准备好文件并做好计算，则需要在看到文件之前就准备好这些资料（不过实际应用中，攻击者很可能会选择这么做）。这些都会增加实施中间人攻击的困难。

这次回北京之前的周末，FreeBSD安全团队发表了内部通知，发现 FreeBSD.org 有些机器被入侵，最近终于做了全面披露了。目前，基本的代码审计和攻击检查已经做完，部分机器还在重装的过程中。

对 FreeBSD 这样的开源项目来说，在基础设施遭到攻击之后，首先必须被怀疑的便是有可能有人在代码库中植入了新的后门。由于代码量十分巨大，逐行审计是非常不现实的。由于 FreeBSD 在 BSD 时代即采用了版本控制系统（最早 BSD 时代是 SCCS，FreeBSD早期是CVS，现在是 subversion），因此，每一行代码的来源，包括作者、具体的修改时间，以及为什么那样修改等等，都可以很容易地查找到。

前几天做一个解离散对数的题用到了 gmpy，它是 GMP 的 Python 封装，用来算大数。

这里记两笔。首先是大整数需要用 mpz 对象，例如：

p = mpz(13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084171)

判断大数是否是质数：is_prime(p) （求离散对数其实用不着）

求逆元 $x^{-1}$：invert(x, p)。例如， y = invert(x, p) 则 $(x * y) \mod p = 1$

正确地使用一次性密码本进行加密，在理论上是无法破解的。需要注意的是，许多对称式加密算法本质上是通过一定的算法来将密钥作为伪随机数发生器的种子来产生（近似于）一次性密码本的序列，因此类似的问题也需要予以重视：不要重复使用同一个一次性密码本（或密钥）来加密不同的明文数据。

以基本的一次性密码本加密算法，即按字节做 XOR 来看，由于在这个算法中明文和密文的字节位置是一一对应的，很明显，同一个位置的两份密文之间做 XOR，可以知道两份明文之间的 XOR 值（因为在这个过程中，密钥 k 被 XOR 消去了）。

假如明文碰巧又没有做任何压缩处理，实际上我们可以用程序来穷举出部分的密码本，并逐步解出全部明文。具体方法大致如下：

很久以前 Cisco 的 刘老师 就做过蜜罐系统，所谓蜜罐其实是一些"看起来"像是正常，但并不对正常人提供服务的网络资源，例如邮箱、网页，甚至网络服务等等。它们存在唯一的作用是吸引攻击者的机器人来攻击，从而得到关于攻击本身的更多信息，或在攻击开始之前采取防御。这种做法有点像有些国家在火箭基地附近建设几个一模一样的、假的火箭基地，防止敌军轰炸等等。

TextMate 2 宣布开源了，在 一则报道 中指出，这是对苹果 OS X 新增的限制的回应，我对此十分怀疑。

为什么呢？因为沙箱是非常重要的安全机制。沙箱其实到处存在，只不过在过去没有 OS X 中这样全面和细致而已。例如，现代操作系统中两个进程不能随便互相写对方虚拟内存中的内容；又比如，操作系统中通过"用户"、“属主"等概念来进行访问控制，等等。这些机制的存在，限制了由于开发人员偶然犯错导致的损失范围。许多不靠谱而且不负责任的开发者，则会以种种借口指责沙箱拖慢了他们的开发进度。更有甚者，其中的一些甚至还会告诉用户打破沙箱（例如比较常见的是很多 php 应用建议用户 chmod -R 777），其结果则必然是在发生问题时产生更大的损失。

早期的 FreeBSD 版本中采用的是 md5crypt，其作者 Poul Henning-Kamp 最近发表了一篇文章：Md5crypt Password scrambler is no longer considered safe by author，所以 FreeBSD 预设的密码格式也就随之改成了 SHA512 crypt。

官方版本的 nginx 在 https 的时候是不对流量做压缩的，具体原因在这里 和 这里 有解释，它会增加半兆的连接内存开销。

启用 https 压缩除了需要 nginx 本身做少量修改（例如去掉 if[n]def SSL_OP_NO_COMPRESSION 部分的语句块）之外，还需要 OpenSSL 本身编译了加密支持。FreeBSD ports 的 security/openssl 预设启用了 ZLIB 扩展，但基本系统目前没有（由于 zlib 是很大的一片代码，也许需要做了 Capsicum 处理之后才可以放进来用）。