OpenSSL

原定4月25日开始的code slush和KBI冻结并未发生，主要的原因是 OpenSSL 3.0 还未合并， 以及 OpenZFS 近期的一些可靠性问题。

其中，OpenSSL 3.0 由于对 API 的改动比较大，因此会导致一些 port 无法正常工作 （PR 258413）。 近期已经有一批 port 标记为与 OpenSSL 3.x 不兼容， 不过修掉这些可能会需要不少时间。

昨天，FreeBSD 13.2 正式发布了。 kTLS 是在 FreeBSD 13.0 中由 Netflix 赞助的新功能， 过去，TLS/SSL 应用程序对于通讯内容的加解密通常是在用户态进行的，这样一来， 系统在读取出数据和发出数据之前需要进行额外的上下文切换，并在内核和用户地址空间之间来回复制缓冲区来满足加解密的需要。 有了 kTLS 之后，内核可以在 sendfile(2) 时直接在内核上下文中完成加密和填充到网络协议栈的操作，从而减少了上下文切换和不必要的复制操作。

今天早上4点多就爬起来准备发安全公告（友商约的是早上5点发），一刷，OpenSSL官方已经正式发表了（时间大约是4点30），于是立即开始相关手续，commit修正，发公告，通知CERT，这些不表。

这次 Heartbleed 安全漏洞之后，阿里巴巴集团的多个产品均迅速修复了漏洞（好事），但事后的公关处理做的却有待改进。

我在微博上看到有人转发 阿里安全 在4月9日13:01发表的一篇微博，内容如下：

关于OpenSSL某些版本存在基于基础协议的通用漏洞，阿里各网站已经在第一时间进行了修复处理，目前已经处理完毕，包括淘宝、天猫、支付宝等各大网站都确认可以放心使用。

紧接着， 支付宝 转发了 这条微博：

大家可以放心了！

我并不是阿里巴巴/支付宝的客户，不过看到有人转发这条消息，我半开玩笑地 回了一句：

冲这句「大家可以放心了」就没法放心了……

OpenBSD [捐款链接] 又一次出手为民除害了！ Undeadly报道： OpenBSD has started a massive strip-down and cleanup of OpenSSL。

这次 Heartbleed 的事情搞的我十分不爽，这事固然不能全怪 OpenSSL 的开发者，但是整个过程非常的让人不舒服，具体的就不多说了。等过个几十年再回头看看这次这件事情再说吧。

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

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

最近改一个用到 OpenSSL 的程序，顺手用 valgrind 抓了一下，发现很多「Conditional jump or move depends on uninitialised value(s)」的错误。发现 OpenSSL 的 FAQ 提到，在生成随机数时会将输入缓冲区（未初始化）的内容直接混入 entropy pool，使用 valgrind 时便会导致警告。

📓 注意

2015-03-05更新：本文中部分干货已过时，本文本身也不再更新。请参阅 这张作弊条。由于 ACME 协议的普及，现时通常只需生成密钥对即可。

SSL/TLS协议中，服务器证书是用于向客户端证明服务器身份的凭据，同时它还向用户提供了服务器的公钥，而服务器公钥则可以用来建立客户端到服务器的安全通讯（具体的通讯流程要比这个复杂，纯从技术而言，服务器的公钥主要用于与客户端进行会话密钥的协商）。

服务器的公钥只能确保拥有私钥的服务器（或人）能够解密信息，但它本身并不能确认服务器的身份。在实践中有很多种不同的方法来确保公钥确实来自受信任的服务器，在通常的SSL/TLS协商过程中，采用的方法是根据证书链来逐层验证公钥是否是有效的及其身份。简单地说，就是以安全的方法（例如安装光盘，或互相认证的签名等）事先将证书链上的某一个或某几个证书发给客户端，以便其验证最终用于服务器的安全证书。关于这一流程的具体细节，已经有很多文章进行了介绍，在此不再赘述。

如此，我们在实现采用SSL/TLS的服务器的时候，需要为证书准备的事项包括：

• 找到一家被客户端信任的、具备签发证书资质的发证机构。发证机构可以是根CA（对于浏览器来说，通常可以在安全选项中找到类似"查看证书"之类的选项），也可以是这些根CA认可的二级发证机构。
• 收集用于验证服务器身份的信息，例如服务器的FQDN，等
• 生成一对用于SSL/TLS的公钥/私钥。

有了这些信息，就可以制作证书申请（CSR）供发证机构去签名了。一般来说，发证机构需要首先验证申请人的身份信息，然后对CSR提交的信息进行核对和签名，并将签名之后的证书发给申请者，或供其下载。下面以 FreeBSD、OpenSSL 为例介绍从生成公钥/私钥对到签发、安装证书的全过程。

以下内容为作弊条，仅供参考；只保证在FreeBSD下能用。

为postfix配置TLS的关键是产生自己的CA证书，并签署一年一续的服务证书。注意一定要保管好前者的私钥！

第一步，创建自签名CA：

mkdir /usr/local/etc/ca
cd /usr/local/etc/ca
mkdir certs crl newcerts private
echo 「01」 > serial
cp /dev/null index.txt
cp /etc/ssl/openssl.cnf openssl.cnf
vi openssl.cnf