UGFzc3dvcmQ6 是什么？
今天无意中看了一眼服务器日志，结果发现了一些奇怪的消息：
| |
这里的 UGFzc3dvcmQ6 是什么呢？从直觉上看似乎是个 base64 编码的字符串。解码试试看，果然：
Security
共295篇文章。
Telegram Premium
作弊条：SSH 的 ProxyJump 跳板服务
问题
有些环境中，SSH 服务器可能无法从 Internet 直接访问（例如，SSH 服务器可能使用的是一个私有 IP地址，或是 Internet 服务提供商没有提供 IPv6 服务，而 SSH 服务器只提供 IPv6 服务）。
考虑到 SSH 已经进行了相互认证（连接时客户端会验证服务器的公钥是否与已知公钥，例如 ~/.ssh/known_hosts，或是通过 DNSsec 发布的 SSHFP RR 匹配；服务器端则会验证用户是否能证明自己拥有与授权公钥对应的私钥），因此比较常见的解决方法便是使用 VPN、在防火墙上穿孔，或是使用代理服务器。
由于 SSH 自身也提供了许多转发功能，因此如果中间的跳板服务器也提供 SSH 服务，便可以使用这些跳转服务器直接作为代理服务器来用。与前面那些传统方法相比，这样做的优点是避免了安装额外的软件，也不需要特别指定端口。
用 FIDO key 来做 SSH key
OpenSSH 8.2 中新增了 FIDO/U2F 支持。它支持两种密钥对类型： ecdsa-sk 和 ed25519-sk。需要注意的是并非所有的 FIDO Security Key都实现了 ed25519-sk 的硬件支持：例如，截至2022年，Titan Security Key
就不支持 ed25519-sk。
使用 FIDO key 的 SSH key 在使用上和之前的 SSH key 类似，主要的区别在于在登录时系统会确认用户是否在机器旁边（通常是碰一下 FIDO key），这可以显著地改善安全性：与之前的 SSH key 不同的是，即使机器上的 U2F/FIDO SSH key 私钥文件被攻击者获得，在没有硬件 FIDO key 的情况下也无法使用这个私钥。对于对方同时能获得私钥文件和物理访问的情况，参见 xkcd/538，就不要跟扳手过不去了。
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 的根证书过期了。这样一来，这一边的信任链便不再成立。
记一件糗事：术后清理要做好
今天和 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/consolegeli(8)的HMAC设计
读到哪算哪的先记一笔。
geli(8)在启用了数据完整性检测的时候采取的设计是将HMAC数据保存在同一扇区中，换言之它在保存数据时，物理扇区（通常是512字节）中占用了32字节来保存HMAC数据。
用 Pomerium 来实现基于身份的访问控制
Google 在十年前提出了一套名为 BeyondCorp 的零信任网络的安全方案。这套方案想要完整地实现还是有一定门槛的，在这种模型下，企业内网不再作为一个安全边界存在，相反即使在内网进行的访问也必须进行和外网同样的鉴权与访问控制。最终的改造方向是内网不再是一个特权网络，每个终端上部署的客户端证书主要是作为一项身份信息来使用。
这也太不注意卫生了
razor 同学对于 Xcode ghost 的事情的评价是：这也太不注意卫生了。个人深以为然。
技术细节、影响等等，已经有很多大牛写过很好的文章来介绍。但是我想问的是，这事完了吗？在我看来远远没有，根据有关厂商的介绍，想要装上这个下了马的 Xcode，首先得从 App Store 以外的渠道去下载，其次还得允许运行来自 ‘Anywhere’ 的应用程序，或者开发人员习惯于绕过系统的数字签名检查。
还是得提高知识水平
📜 历史文件已不具备现实意义
freebsd-update目前已进入维护状态并可能在后续 FreeBSD 版本中逐步被替换掉。
今天搞了一个 大新闻。如果你用BIND并且今天之前没打过补丁的话，请读到这里为止，立即去补吧。
我觉得还是得提高知识水平。做 freebsd-update 补丁的时候，赫然发现修改的文件中有一个不认识的：