Security
自建权威 DNS 的利弊
TL;DR：我的观点是现时 (2023) 大多数人都不应该自建 DNS，而应该找一家比较可靠的供应商。
下面说说我的理由。
阅读全文…再谈域名注册服务提供商的选择
近期由于一些众所周知的原因，我做了一系列域名转移的操作。和 2006 年的这篇相比， 这些年我也经历了不少域名注册服务提供商，并且积累了不少经验，是时候更新一下了。
域名服务是一项互联网基础服务，它提供了容易被人记忆和识别的在线地址。对于个人和企业来说， 拥有自己的域名最大的好处在于能够掌握随时换一家供应商的议价权。集中式的平台， 包括 YouTube、Twitter、GitHub，也包括新兴的平台如 TikTok、 或是来自中国的小红书、喜马拉雅、B站等等，尽管也都是很好的产品， 有些甚至可以为内容作者带来丰厚的回报，但是其上的个人或是企业无法很容易地离开这些平台。 依赖这些平台，意味着在它们选择对内容作者采取某些行动，或是退出某项生意的时候， 当事人可能没有任何其他选择，而必须在极短的时间内通知自己的受众去其他平台， 这有时是很困难甚至不可能的。
对个人来说，邮件服务的运行成本是很高的（这里需要考虑的不仅是服务器本身的成本和运行费用， 也包括需要投入的时间精力）。但即使不自己去运行邮件服务，也仍然有许多支持独立域名的邮件服务提供商， 例如 Google Workspace、 Microsoft 365、Zoho Workplace等等。与单纯使用 Gmail 或 outlook.com 等等相比， 拥有独立的域名意味着可以在这些服务之间随时进行转移，而无需逐个通知亲朋好友。
阅读全文…带 DNSSEC 的域名转移
DNSSEC 是一组针对 DNS 协议的扩展，其主要目的是为数据的权威性（或者说DNS数据确实来自于有权发布这些数据的人） 提供一套验证机制。DNSSEC并不改善私密性，所有的查询依然是明文的。
目前最新的 DNSSEC 最佳实践指南是 BCP 237 (RFC 9364)。 值得说明的是，如果没有特别的需要，使用 DNS 服务业者的 DNSSEC 实现可以避免踩很多的坑， 尽管这样一来安全方面就完全要仰赖这些业者了， 但对普通的域名所有这来说这些服务要比他们自己去架设和管理要可靠不少。 本文并不打算深入介绍 DNSSEC 及其部署，而只是关注于在进行域名转移时需要注意的问题， 以备我个人未来进行参考。
阅读全文…关掉了 Google 账户的 passkey
最近， Google 账户新增了一种叫做 passkey 的登录方式。
传统的采用密码登录的登录方式中，用户需要用某种方式证明自己知道密码，而绝大多数实现中这意味着网站必须保存用户的密码， 或是密码的 hash 值（通常是HMAC），这意味着网站如果发生了拖库的情况，有可能会将用户的密码或其 hash 值泄漏出去。 此外，用户可能必须输入密码，并将密码通过某种方式传输到服务器上，这样一来在这个过程中便有可能由于本地的木马， 或是网站采用的 SSL/TLS 实现的漏洞导致密码泄漏。除此之外，即使用户十分小心地在每一个不同的网站都使用了不同的密码， 他们仍然需要担心被「钓鱼」的问题，所谓「钓鱼」是这样一种攻击方式：攻击者架设一个看起来很像是用户希望登录的网站的网站， 并诱骗用户输入密码。
阅读全文…FreeBSD 上的 nginx kTLS 支持
昨天，FreeBSD 13.2 正式发布了。 kTLS 是在 FreeBSD 13.0 中由 Netflix 赞助的新功能， 过去，TLS/SSL 应用程序对于通讯内容的加解密通常是在用户态进行的，这样一来， 系统在读取出数据和发出数据之前需要进行额外的上下文切换，并在内核和用户地址空间之间来回复制缓冲区来满足加解密的需要。 有了 kTLS 之后，内核可以在 sendfile(2) 时直接在内核上下文中完成加密和填充到网络协议栈的操作，从而减少了上下文切换和不必要的复制操作。
阅读全文…iCloud 的 Advanced Data Protection
最近 Apple 的一系列更新中的一项新的安全特性是 iCloud 的 Advanced Data Protection， 大概看了一下还是挺有意思的。
阅读全文…UGFzc3dvcmQ6 是什么？
今天无意中看了一眼服务器日志，结果发现了一些奇怪的消息：
| |
这里的 UGFzc3dvcmQ6 是什么呢？从直觉上看似乎是个 base64 编码的字符串。解码试试看，果然：
作弊条：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，就不要跟扳手过不去了。
阅读全文…指定 fetch(3) 的 User-Agent
今天抽时间把邮件系统的软件升级了一下，然后发现无法获得 ClamAV 的源代码：
| |
同一个链接用浏览器是能打开的，一看邮件果然已经有人 开过票 了。
最近发现不少网站都出于某种原因对 User-Agent 进行了限制，不过既然这是个用户能自行指定的值，
这么限制到底意义何在呢？