NTS：Meta 的认证时间服务
内容提要
Meta 推出 NTS 认证时间服务 nts.meta.com，利用 TLS 密钥交换和加密 Cookie 验证时间来源，防止中间人攻击。服务器无状态，密钥按天派生，代码已开源。NTS 可防伪造但无法防延迟攻击，移动端 Android 和 iOS 仍缺乏支持。
延伸解读
证书有效期缩短，时间同步的紧迫性升级
文章指出，CA/Browser Forum 的 SC-081v3 提案将公开信任的 TLS 证书最长有效期从 398 天逐步缩短：2026 年 3 月降至 200 天，2027 年 3 月降至 100 天，2029 年 3 月降至 47 天，同时域名验证复用期也缩短至 10 天。这意味着证书续期将完全自动化，通常通过 ACME 进行。如果主机时钟偏移，自动续期循环可能在不被察觉的情况下失败或错误重签，导致服务中断。因此，可靠且可验证的时间源变得至关重要。
无状态 Cookie 设计：简化运维，避免密钥同步
NTS 服务器不保存每个客户端的状态，也不复制密钥环。每个服务器从共享主密钥和当前天数派生出 Cookie 密封密钥，公式为 key = HKDF-SHA256(master, salt = BE32(day), info = “fbnts-cookie-seal-v1”)。天数按 Unix 纪元以来的完整 24 小时周期计算，无时区或夏令时问题。服务器接受过去两天和未来一天的密钥以覆盖时钟偏差。这种设计消除了密钥复制、会话表和共享状态同步问题，使添加服务器变得简单，且不会成为攻击者耗尽资源的入口。
NTS 的防护边界：防伪造，不防延迟
NTS 能有效防止中间人攻击伪造时间响应，因为数据包经过认证，伪造包会被丢弃。但 RFC 8915 明确指出，NTS 无法防御延迟攻击：攻击者可以延迟数据包，使客户端时钟偏移最多为引入延迟的一半，而所有字节都是真实的，协议无法检测。此外，NTS 不解决引导问题（TLS 需要大致正确的时间）、错误服务器（认证路径而非答案）和单调性问题（墙钟可能回退）。因此，仍需多源、合理性检查和监控。
移动端缺失：NTS 普及的最大短板
尽管 NTS 在服务器端已有 chrony 和 ntpsec 等实现，但移动平台仍缺乏支持。Android 的平台时间同步使用明文 SNTP over UDP/123，不处理扩展字段；Apple 设备通过 timed 同步，也未发现 NTS 支持。这两个栈为数十亿手机、手表和头戴设备设置时钟，却仍信任未认证的 UDP 包。设备厂商可以单独发布支持 NTS 的客户端（如 chrony 可在 Android 上运行），但这只是权宜之计，平台本身应集成 NTS。
Q&A
Meta 的 NTS 认证时间服务是什么？
Meta 的 NTS 认证时间服务是 Meta 公共时间服务在 nts.meta.com 上支持 NTS（网络时间安全，RFC 8915）。数据包经过认证，设备可以验证时间来自 Meta 且未被修改。服务器无状态，Cookie 密钥派生而非存储，代码已开源。
NTS 如何工作？
NTS 分两阶段：1) 密钥建立（NTS-KE）：通过 TCP/4460 上的 TLS 1.3 协商 AEAD 算法，派生会话密钥，服务器发放 8 个 Cookie 并告知实际 NTP 服务器地址。2) 认证 NTP：通过 UDP/123 发送带扩展字段的 NTPv4 包，使用 Cookie 和认证器验证数据包，响应中加密携带新 Cookie。
NTS 能防御哪些攻击？
NTS 能防止中间人攻击伪造时间应答，确保时间来源真实且未被篡改。攻击者无法回拨或前拨时钟来使过期证书或令牌重新生效。
NTS 有哪些局限性？
NTS 无法防御延迟攻击，攻击者可以延迟数据包使时钟偏移，但无法篡改内容。此外，NTS 需要初始时钟大致正确以完成 TLS 握手；无法防止服务器本身提供错误时间；认证时间仍是墙钟时间，可能因闰秒或校正而回退。
如何在客户端配置使用 Meta 的 NTS 服务？
在 chrony 配置中添加一行：pool nts.meta.com nts iburst maxsources 5。nts.meta.com 仅用于密钥交换，会通过服务器协商记录将客户端引导至 time.meta.com 进行认证 NTP。使用 pool 可获取多个独立源，提高可靠性。
NTS 在移动端（Android 和 iOS）的支持情况如何？
Android 和 iOS 的默认时间客户端均不支持 NTS。Android 使用普通 SNTP over UDP/123，无扩展字段处理；Apple 设备通过 timed 同步，也未支持 NTS。这些平台为数十亿设备设置时钟，但仍在信任未认证的 UDP 包。
