Security

Ed25519 是一种高性能的公钥签名系统。和 RSA 相比，同等强度的 Ed25519 的密钥长度要比 RSA 短很多，此外，软件实现的 Ed25519的验证速度也比同等强度的 RSA 快很多。

尽管早在2018年 RFC 8463 Section 5就已经将 RFC 6376 Section 3.3 修正为要求验证者必须支持 Ed25519 验证，然而时至今日主要的邮件服务提供商中，包括 Google 的 Gmail 和 Microsoft 的 Outlook.com 以及 Apple 的 iCloud都还不支持验证 Ed25519 DKIM 签名。ProtonMail 支持 Ed25519 的 DKIM 签名，但它并不使用Ed25519 签名向外发出的邮件。

目的

在本地的局域网上建立 DNS 解析服务可以显著地改善 DNS 的安全性：所有的 DNS 查询将由可以信任的本地 DNS 解析服务进行验证，而不是简单地相信一台不受控的远程服务器通过 UDP 提供的应答。因此，这些年来我自己的网络包括机房的网络都是自己运行一组 DNS解析服务的。

近期由于一些众所周知的原因，我做了一系列域名转移的操作。和 2006 年的这篇相比，这些年我也经历了不少域名注册服务提供商，并且积累了不少经验，是时候更新一下了。

域名服务是一项互联网基础服务，它提供了容易被人记忆和识别的在线地址。对于个人和企业来说，拥有自己的域名最大的好处在于能够掌握随时换一家供应商的议价权。集中式的平台，包括 YouTube、Twitter、GitHub，也包括新兴的平台如 TikTok、或是来自中国的小红书、喜马拉雅、B站等等，尽管也都是很好的产品，有些甚至可以为内容作者带来丰厚的回报，但是其上的个人或是企业无法很容易地离开这些平台。依赖这些平台，意味着在它们选择对内容作者采取某些行动，或是退出某项生意的时候，当事人可能没有任何其他选择，而必须在极短的时间内通知自己的受众去其他平台，这有时是很困难甚至不可能的。

对个人来说，邮件服务的运行成本是很高的（这里需要考虑的不仅是服务器本身的成本和运行费用，也包括需要投入的时间精力）。但即使不自己去运行邮件服务，也仍然有许多支持独立域名的邮件服务提供商，例如 Google Workspace、Microsoft 365、Zoho Workplace等等。与单纯使用 Gmail 或 outlook.com 等等相比，拥有独立的域名意味着可以在这些服务之间随时进行转移，而无需逐个通知亲朋好友。

DNSSEC 是一组针对 DNS 协议的扩展，其主要目的是为数据的权威性（或者说DNS数据确实来自于有权发布这些数据的人）提供一套验证机制。DNSSEC并不改善私密性，所有的查询依然是明文的。

目前最新的 DNSSEC 最佳实践指南是 BCP 237 (RFC 9364)。值得说明的是，如果没有特别的需要，使用 DNS 服务业者的 DNSSEC 实现可以避免踩很多的坑，尽管这样一来安全方面就完全要仰赖这些业者了，但对普通的域名所有这来说这些服务要比他们自己去架设和管理要可靠不少。本文并不打算深入介绍 DNSSEC 及其部署，而只是关注于在进行域名转移时需要注意的问题，以备我个人未来进行参考。

最近， Google 账户新增了一种叫做 passkey 的登录方式。

传统的采用密码登录的登录方式中，用户需要用某种方式证明自己知道密码，而绝大多数实现中这意味着网站必须保存用户的密码，或是密码的 hash 值（通常是HMAC），这意味着网站如果发生了拖库的情况，有可能会将用户的密码或其 hash 值泄漏出去。此外，用户可能必须输入密码，并将密码通过某种方式传输到服务器上，这样一来在这个过程中便有可能由于本地的木马，或是网站采用的 SSL/TLS 实现的漏洞导致密码泄漏。除此之外，即使用户十分小心地在每一个不同的网站都使用了不同的密码，他们仍然需要担心被「钓鱼」的问题，所谓「钓鱼」是这样一种攻击方式：攻击者架设一个看起来很像是用户希望登录的网站的网站，并诱骗用户输入密码。

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

上回书 说到留言板的问题时提到留言板当时没有解决，在文内的模板中可以看到我当时是采用了一种非常对付的方法：直接将之前的评论直接作为文章内容输出出来。这导致了页面不太美观。

趁着周末我把之前 Movable Type 的数据库重新捋了一下，把其中的 2256 条留言用类似 isso迁移时的方法转换成了 json，然后就可以在 remark42 中导入了。中国有句俗话叫三搬一火，意思是搬三次家大约等于失一次火，这次留言内容搬家我也丢掉了一些东西：Remark42 的一项设计理念便是尽量不保存可以追踪用户的数据，例如用户的 E-mail 在 Remark42中只会保存一个与之对应的 SHA1，对于网站的主人来说，这意味着他们不能直接从这些保存的数据中获得用户的 E-mail 地址（当然，实际情况中，这类单向函数并不能阻止他们在知道这些信息的情况下验证某个 SHA1是不是某个 E-mail 地址，但总归这要比把数据存在数据库里安全得多），因此这个迁移过程也就意味着所有相关的明文数据消失了。除此之外，Movable Type还保存了许多类似于用户网站地址这样的信息，我在转换时考虑了一下，由于许多人的网站都已经不在了，迁移的意义不太大，因此最终决定不迁移这些数据了。

考虑到现在还在用 Movable Type 的人应该已经没有几个了，我感觉我的方法可能对其他人没有太大的参考意义，这里只是简单做个记录。代码写的比较乱，就不拿出来丢人了。

这几天收到了几次来自 Facebook 的通知，第一次是 “Request for Information/Action” （最早申请时还没有 Privacy Policy，但后来补上了），但过了几天之后系统表示无法完成compliance review，并直接禁用了该 App。

上回书 说到启用了基于 isso 的评论系统，其实当时还发现了一个功能相当强的评论系统 remark42，但该系统是 Go 写的，并且依赖的其他软件包要比 isso 多不少，因此当时没有下定决心换成这个。

最近 Apple 的一系列更新中的一项新的安全特性是 iCloud 的Advanced Data Protection，大概看了一下还是挺有意思的。