OpenSSL

FreeBSD 14 确定延期

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

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

FreeBSD 上的 nginx kTLS 支持

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

Let's Encrypt SSL证书失效问题

Let’s Encrypt 是我目前使用的证书发证机构。早上 yegle 提到了某个bug，于是研究了一下，这里记一笔，算是留个历史见证吧。

发生了什么

在 PKI 证书体系中，信任是通过逐级签名以及对这些签名的验证来实现的。 对大部分客户端系统来说，这些系统中会存在一个或多个受信的根证书发证机构的证书， 其公钥是通过这些系统本身的更新机制派发的。

根证书发证机构的证书通常是自签名的，更新相对来说比较麻烦（它通常依赖于操作系统的在线或离线更新机制）， 因此这些证书的私钥事关重大，因此人们通常不希望经常更新它们，因而证书发证机构在绝大多数时候并不会使用这些私钥来签署证书。 取而代之的是，他们会创建一些称为中级发证机构的证书用来签署日常的证书，这样根证书的私钥可以采用更为严密的方法来保护， 例如可以把它们从网络上彻底断开，而中级发证机构的证书则可以以较高的频率进行密钥轮换，借此来避免其私钥暴露导致的风险。

一个新的发证机构进入市场时，其自签名的根证书往往不会被已经在市场上的客户端系统认可， 因此这样一来新的发证机构想要获得用户就必须想办法解决能被用户承认这个问题。 一旦获得了一定的知名度并证明了自己的可靠性， 这些发证机构便可以遵循一定的流程获得主流浏览器或操作系统的认可， 并将自己的根证书也加入到它们的受信根证书列表中了。 所以，在起步阶段，新的发证机构往往会要求一些已经存在的根证书去对其根证书进行交叉签署， 在客户端验证证书有效性时，由于这些根证书在他们看来是一个经过了受信根证书签名的中级证书而不是一个普通的不受信自签名根证书， 因此也就不会给出无法验证证书是否有效的提示，而是能够正确地对其有效性进行验证了。

Let’s Encrypt 在起步阶段正是采用了这种做法。通俗地说，它的中级发证机构的证书被两家根证书机构同时签名， 其一是它自己的 ISRG Root，另一个是另一家根证书机构 IdenTrust 的 DST Root X3。初期，由于 DST Root X3 已经被许多操作系统和浏览器认证过，因此为其普及起到了非常重要的作用。

UTC 时间 2021年9月29日 19:21:40，DST Root X3 的根证书过期了。这样一来，这一边的信任链便不再成立。

OpenSSL 的新一批漏洞

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

Heartbleed之危机公关处理

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

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

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

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

大家可以放心了！

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

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

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

如何：申请用于服务器SSL/TLS的X.509证书

📓 注意

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

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

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

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

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

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