Security

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

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

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

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

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

趁着周末我把之前 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，大概看了一下还是挺有意思的。

今天无意中看了一眼服务器日志，结果发现了一些奇怪的消息：

1
2
3
4
5
6
7
8
9

warning: unknown[122.168.199.151]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[176.8.89.240]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[185.232.21.42]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[206.217.216.13]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[220.196.249.145]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[5.253.204.74]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[70.45.212.49]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[93.177.73.82]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[93.177.75.66]: SASL LOGIN authentication failed: UGFzc3dvcmQ6

这里的 UGFzc3dvcmQ6 是什么呢？从直觉上看似乎是个 base64 编码的字符串。解码试试看，果然：

Telegram 最近宣布了其订阅付费计划。说起来我也不是特别信任其安全/隐私方面的特性(*)，不过作为一个跨平台即时通讯软件来说，其在不同平台上的功能基本上做到了完全一致，并且在这个礼崩乐坏 的时代，能够在不同平台上都做到不狂吃CPU/内存，在不同平台上的界面行为上高度一致，并且完全没有各种令人抓狂的智障设计（举例来说：随便干什么事情都弄个二维码还非让你扫描一下借此获得摄像头权限、多机登录时以手机为主并且时不时就得再扫描一次二维码、完全无法回溯的会话引用、没头没脑地给一条「有人@你」的通知，却无法迅速定位到消息等等），并且公开客户端源代码以便第三方进行代码审计，确实是十分难得的。

问题

有些环境中，SSH 服务器可能无法从 Internet 直接访问（例如，SSH 服务器可能使用的是一个私有 IP地址，或是 Internet 服务提供商没有提供 IPv6 服务，而 SSH 服务器只提供 IPv6 服务）。

考虑到 SSH 已经进行了相互认证（连接时客户端会验证服务器的公钥是否与已知公钥，例如 ~/.ssh/known_hosts，或是通过 DNSsec 发布的 SSHFP RR 匹配；服务器端则会验证用户是否能证明自己拥有与授权公钥对应的私钥），因此比较常见的解决方法便是使用 VPN、在防火墙上穿孔，或是使用代理服务器。

由于 SSH 自身也提供了许多转发功能，因此如果中间的跳板服务器也提供 SSH 服务，便可以使用这些跳转服务器直接作为代理服务器来用。与前面那些传统方法相比，这样做的优点是避免了安装额外的软件，也不需要特别指定端口。

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，就不要跟扳手过不去了。