摘要

  • LACNIC 的内容编号 4984 在其公共主机上展示 /rpki/lacnic.tal 与 /rpki/lacnic-as0.tal，底层 href 却保留了两条 /innovaportal/file/4983/1/ 路径。
  • 8 月 30 日，两条展示地址都以 HTTP 200 返回 text/html，长度同为 7,014 字节，SHA-256 完全相同；两条真实目标则交付了 502 与 518 字节的不同 TAL 文本。
  • 两份 TAL 指向不同证书，两张证书也都能取回。现有证据仅能证明发布标签与交付目标分裂，不能证明验证器、仓库、密钥、ROA 或路由发生故障。
  • 发布收据应同时核对可见文字和解析后的 href，并把媒体类型、TAL 语法、文件哈希、证书关系及纠正沿革连在一起。

先别谈密钥，先看链接到底说了什么

LACNIC 的 RPKI Trust Anchors - TAL 页面先列出普通信任锚，再说明 AS0 政策需要专用 TAL。页面末尾称文件可从两个链接下载，并把两个完整地址直接写给读者。

可是，CMS 的 4984 号内容保存了另一层信息。普通 TAL 的可见文字下面是 /innovaportal/file/4983/1/lacnic.tal，AS0 的可见文字下面是 /innovaportal/file/4983/1/lacnic-as0.tal。前端环境文件又把 Innovaportal 基址声明为 innova.lacnic.net/innovaportal。

于是，同一条编辑指令产生了两种执行方式。鼠标点击读取 href，沿着旧文件服务走；复制可见文字则请求新站点的 /rpki/ 路由。人工检查者通常只点击，运维人员却可能把文字粘进脚本、工单或配置说明。两者都以为自己使用了“页面上的链接”。

旧路径本身并非问题。文件下载服务、内容迁移和稳定别名都可以合法存在。真正需要说明的是：哪一个地址是规范入口，另一个地址与它是什么关系。

两个绿色状态码，交付的是一份网页

2026 年 8 月 30 日 04:48 UTC，研究对两条展示地址做了绕过缓存的请求。普通地址与 AS0 地址均返回 HTTP 200，内容类型均为 text/html。

两份响应都是 7,014 字节，SHA-256 都是 7a17eab5484db68fe84e396d8fb7b6326cfff37d10c7467c0296655a899dc416，Last-Modified 也都是 2026 年 8 月 28 日 13:20:15 GMT。逐字节看，它们是同一份 LACNIC 应用入口 HTML，不是普通 TAL 与 AS0 TAL。

这个时间戳不能反推出分裂从何时开始，也不能证明各地缓存一直给出相同结果。此次采集更没有观察到任何用户或验证器使用这些展示地址。

但它足以否定“200 就代表 TAL 可用”的监控逻辑。状态码只证明服务器成功返回某个表示。若监控继续检查证书 URI、空行和公钥材料，HTML 会在进入任何密码学判断之前被识别出来。

点击目标留下了清晰的反证边界

普通 TAL 的 Innovaportal 目标返回 application/aux、502 字节，SHA-256 为 d44bb9394ab009c8b53e5efebf2a1c9450bab61a27efe00de5a3e4587a3a2f6a。其中列有普通证书的 HTTPS 与 rsync 位置以及公钥材料。

AS0 TAL 目标返回 518 字节，SHA-256 为 671a1b78c51ac023e7500212f0039699e94f4143eab05260284eccc3858e9eff。它指向另一个仓库位置、另一张证书，也包含不同的公钥。

随后取回的普通证书为 1,166 字节，AS0 证书为 1,160 字节。两者都是不同的二进制对象。

这组结果很重要，因为它规定了报道的上限：文件交付链的后一段仍然工作，不能把前端地址错配写成仓库离线，更不能写成证书、密钥或 ROA 失效。LACNIC 页面还说明，多数验证工具已经内置所需 TAL；因此也不能凭这两个 URL 推算影响面。

.tal 后缀不等于 TAL 语法

RFC 8630给出的结构很具体：一条或多条按顺序排列的证书 URI，随后是空行，再随后是 Base64 编码的信任锚公钥。依赖方还要获取当前的自签名 RPKI CA 证书，并核对证书公钥是否与 TAL 一致。

因此，至少有五个可区分状态：URL 能解析、HTTP 有响应、响应可按 TAL 解析、证书能获取、公钥能匹配。任何前一步的成功都不能替代后一步。

本次事件又加了一个更靠前的状态：显示给读者的 URL，是否与点击后解析出的 URL 相同。HTML 允许两者不同，且差异有时有充分理由；但对启动信任材料而言，这种差异必须成为显式元数据。

因为 URL 会离开浏览器。它会进入自动化、维护手册、审计底稿和事故记录。只有点击时才有效的标签，与复制后也能获取同一对象的公共地址，不是同一种发布承诺。

最克制的解释仍然足够推动修正

现有事实最符合一次前端迁移或路由别名不完整：新站点接管了 /rpki/，对两个文件名都送出应用外壳；CMS 中的旧文件目标则继续提供 TAL。信任材料没有从可观察位置消失。

LACNIC 可以选择把页面文字改成实际目标，也可以让两条展示地址直接交付或重定向到对应 TAL。报道无须决定哪套架构更好。公共控制只需要点击、复制和机器检查最终指向同一个已声明对象。

若静默修复，未来使用会改善，但旧采集的上下文会消失。简短的纠正说明或可机读收据可以保留旧页面哈希、旧地址关系、修正时间与新规范状态，使外部人员不必在“旧证据错误”和“页面后来改变”之间猜测。

把标签、动作和对象合成一张收据

每个下载元素都应记录页面版本、可见文字、原始 href、解析后的绝对目标、普通或 AS0 角色、预期媒体类型以及别名状态。探针必须分别请求展示 URL 和目标 URL。

每个响应应保存状态码、类型、长度与强哈希，然后检查 TAL 语法，提取 URI 与公钥，获取首选证书，并记录有效期、自签名状态与密钥匹配。发现 HTML 时，系统应报告“发布交付不一致”，而不是越权判断整个 RPKI 无效。

收据还要记住前一版。检测时间、旧页面哈希、原因类别、替代关系和保留别名共同构成纠正沿革。这样既能快速修复，也不会抹掉曾经公开过什么。

此次采集里，两个点击都成功，两个展示地址也都返回 200；只有每对中的一个路径交付了标签承诺的语法。可用性与身份需要两套证据，差别正在这里。

来源