Security

Let's Encrypt SSL证书失效问题

| Security | #Let's Encrypt | #SSL | #BoringSSL

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 的根证书过期了。这样一来，这一边的信任链便不再成立。

阅读全文…( 本文约 1605 字，阅读大致需要 4 分钟 )

记一件糗事：术后清理要做好

| Security | #FreeBSD

今天和 Henry Hu 聊起 iichid 已经进了 FreeBSD 的主线， 想起自己之前鼠标啥的还是都在用 sysmouse，觉得既然来都来了就索性都改成 evdev 的输入设备算了？ 改了 /boot/loader.conf 并增加了下列设置：

iichid_load="YES"
usbhid_load="YES"
hms_load="YES"
hw.usb.usbhid.enable="1"    # 防止uhid(4)接管

重启。等等，一闪而过的那是什么？

ntpd is not allowed to log in on /dev/console
阅读全文…( 本文约 1449 字，阅读大致需要 3 分钟 )

用 Pomerium 来实现基于身份的访问控制

| Distributed Computing | Security

Google 在十年前提出了一套名为 BeyondCorp 的零信任网络的安全方案。这套方案想要完整地实现还是有一定门槛的，在这种模型下，企业内网不再作为一个安全边界存在，相反即使在内网进行的访问也必须进行和外网同样的鉴权与访问控制。最终的改造方向是内网不再是一个特权网络，每个终端上部署的客户端证书主要是作为一项身份信息来使用。

阅读全文…( 本文约 919 字，阅读大致需要 2 分钟 )

这也太不注意卫生了

| Security

razor 同学对于 Xcode ghost 的事情的评价是：这也太不注意卫生了。个人深以为然。

技术细节、影响等等，已经有很多大牛写过很好的文章来介绍。但是我想问的是，这事完了吗？在我看来远远没有，根据有关厂商的介绍，想要装上这个下了马的 Xcode，首先得从 App Store 以外的渠道去下载，其次还得允许运行来自 ‘Anywhere’ 的应用程序，或者开发人员习惯于绕过系统的数字签名检查。

阅读全文…( 本文约 710 字，阅读大致需要 2 分钟 )

还是得提高知识水平

| Security

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

freebsd-update 目前已进入维护状态并可能在后续 FreeBSD 版本中逐步被替换掉。

今天搞了一个 大新闻。如果你用BIND并且今天之前没打过补丁的话，请读到这里为止，立即去补吧。

我觉得还是得提高知识水平。做 freebsd-update 补丁的时候，赫然发现修改的文件中有一个不认识的：

阅读全文…( 本文约 412 字，阅读大致需要 1 分钟 )

OpenBSD的spamd

| Security

许久不碰反垃圾邮件的事情了，一来前段时间垃圾邮件确实也没有那么多，加上spamassassin确实相当有效，二来也是因为犯懒。

不过，最近几天垃圾邮件明显比平时多了许多，所以决定坐下来仔细处理一下。

阅读全文…( 本文约 604 字，阅读大致需要 2 分钟 )

FreeBSD -CURRENT随机数发生器问题

| *nix and Win32 Kernel | Security

今天 John-Mark Gurney 修正了一个影响过去4个月左右的 FreeBSD -CURRENT 的随机数发生器问题，具体受影响的版本是 r273872（引入问题）到 r278907 （修正）。

由于问题只影响 -CURRENT，因此我们不会就此发表安全公告。

阅读全文…( 本文约 407 字，阅读大致需要 1 分钟 )

India NIC签发未经授权的 Google SSL证书事件

| Security

详情参见 Google Online Security Blog。

说两个我认为比较有意思的事情：

第一个是 Google 并没有公布作为证据的证书。由于证书是以 CA 的私钥签署，因此这类未经授权的证书本身就可以作为证据。但是，Google这样做（不公布证书）意味着签发者不得不销毁全部签发的证书，而不仅仅是被公布的那些。

阅读全文…( 本文约 362 字，阅读大致需要 1 分钟 )

OpenSSL 的新一批漏洞

| Security

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

阅读全文…( 本文约 779 字，阅读大致需要 2 分钟 )

Intel RDSEED指令

| Security

今天看到 John Baldwin commit 的这个 r266391 增加了相关支持。

RDSEED 和 RDRAND 的区别是 RDRAND 采用的是 128-bit AES 密钥的 CTR-DRBG，而 RDSEED 则是直接从真随机数发生器中获得输出（两者并不是直接使用真随机发生器的输出，这些输出是做过 AES-CBC-MAC 处理的，防止外界通过观测输出了解内部运行的细节），较慢，后者具备 multiplicative prediction resistance 特性。

阅读全文…( 本文约 352 字，阅读大致需要 1 分钟 )