Summary

  • Geoff Huston 在 2026 年 3 月的 APNIC 原文里指出，普通 NTP 通过未认证的 UDP 报文分发时间，收到答案的设备未必能确认谁在答话。
  • NTS 先用 TLS 建立信任，再给频繁交换的授时报文做认证。Huston 的关键要求是：给时钟加锁，也得让它走得准。

想象一间花重金维护的标准钟房。墙内的仪器严丝合缝，墙外的投递箱却允许陌生人替换信封。Huston 写的就是这道墙。在他的 《Securing NTP》中，精密参考时钟提供源头，网络时间协议把读数送给各台机器；传统交换走 UDP，内容明文传输。路径上的冒充或篡改，会让一台机器收到看似正常的错误时间。

这不是显示屏右下角数字跳错那么简单。担任 APNIC 首席科学家的 Huston 举过自己的工作例子：把网页日志、DNS 查询日志和抓包记录拼在一起，几条时间线必须对得上。分布式数据靠时间判断哪份更新；TLS、DNSSEC 等服务也要依赖可信的日期。一个不可靠的共同时间，能把故障带进许多没有钟面的系统。

IETF 的 NTS 规范设计了两段路。设备先通过 TLS 找到密钥建立服务器，核对对方身份，拿到密钥材料和 cookie。接下来，授时仍使用轻量的 NTP 报文，只是带上 cookie 和认证标记。服务器从 cookie 找回所需状态，不用为每个设备长期留一本档案。信件有了签名，邮差仍能快步走。

Huston 不肯只听“更安全”四个字。授时需要测量报文往返的时延；额外处理和抖动会模糊读数。他因此质疑把整个授时交换搬进 QUIC 的收益。RFC 8915也把性能列为明确目标。给秒针穿上盔甲，如果盔甲拖慢秒针，工程师还得回到图纸前。

首次开机还有一道绕口令：设备要检查 TLS 证书的有效日期，往往先得知道现在大致是哪一天；它恰恰正在找时间。规范讨论了保存上次可信时间、使用可靠本地时钟等办法。规范还提醒，攻击者即使碰不到认证内容，也能通过不对称延迟干扰测时。签名解决“谁说的”，路径测量负责“什么时候到的”。

文章最后，Huston 把问题交还给公共服务。他举瑞典提供 NTS 公共授时的例子，反问为何投入公共资金建精密参考设施，却让送出时间的最后一程缺少身份凭证。采购清单上除了钟的精度，还该有新设备如何第一次建立信任、链路故障时又能向谁问时间。