CloudFlare 最近宣布其网络时间安全（Network Time Security，NTS）协议发布第一个主要版本。该版本构建在他们之前发布的 time.cloudflare.com 之上，这是其免费的时间服务，支持网络时间协议（Network Time Protocol，NTP）和 NTS。
CloudFlare 的免费时间服务 time.cloudflare.com，同时支持 NTP 和正在兴起的 NTS 协议。但是，在它发布的时候，并没有太多可用的 NTS 客户端。随着他们的新 CFNTS 项目的发布，CloudFlare 希望能够鼓励 NTS 协议的广泛采用。 NTPSec 最近发布了对 NTS 的支持。
如果你组合使用 time.cloudflare.com 和 NTPsec 或者它们的新 CFNTS 项目的话，CloudFlare 推荐启用 NTS。他们还提到 daemon 需要支持 TLS 1.3。
NTS 是由两个子协议形成的套件。第一个是网络时间安全秘钥交换（Network Time Security Key Exchange，NTS-KE）。该协议负责秘钥材料的创建，并且负责与第二个协议 NTPv4 的参数协商。NTPv4 是当前版本的 NTP 协议，允许客户端与远程的服务器同步时间。
CloudFlare 的加密工程师 Watson Ladd 和软件工程师 Pop Chunhapanya 这样说到：
为了维护 NTPv4 的可扩展性，很重要的一点就是服务器不维护每个客户端的状态。一个很小的服务器就能为数百万个 NTP 客户端提供服务。在提供安全性的同时又能保证这种属性是通过 cookie 来实现的，cookie 由服务器提供给客户端并且包含了服务器的状态。
为了在第一阶段完成这一点，客户端需要发送一个请求给 NTS-KE 服务器并通过 TLS 获取一个响应。在这个阶段，涉及到多个功能：
- 协商在第二阶段使用的 AEAD 算法；
- 协商第二个协议（目前，标准只定义了 NTS 如何与 NTPv4 协作）；
- 协商 NTP 服务器的 IP 地址和端口；
- 创建第二阶段使用的 cookie；
- 从 TLS 会话创建两个对称秘钥（C2S 和 S2C）。
在第二阶段，客户端现在可以安全地与协商过的 NTP 服务器同步它们的时钟。为了确保安全完成，客户端会发送带有四个扩展的 NTPv4 包。第一个扩展为唯一的标识符扩展，包含了用于防止重播攻击的随机 nonce 。第二个扩展是 NTS cookie 扩展，它会为客户端提供两个 cookies 中的某一个。因为只有客户端记得两个 AEAD 秘钥（C2S 和 S2C），所以服务器端需要这个 cookie 来提取秘钥。每个 cookie 中包含了秘钥，这些秘钥由服务器端所持有的秘钥进行了加密。
第三个扩展是 NTS cookie 占位符扩展，这是客户端发送给服务端的一个信号，用来请求额外的 cookie。之所以需要它是为了确保响应不会比请求明显长太多，以避免放大攻击（amplification attacks）。最后一个扩展是 NTS 认证器和加密扩展字段的扩展，它包含 AEAD 算法的一个密文，以 C2S 作为密钥，NTP 头信息、时间戳和所有上述的扩展作为相关的数据。我们需要此头信息来防止时间戳仿造。
按照 Ladd 和 Chunhapanya 所述：
第二次握手可以重复很多次，而不会回到第一个阶段，因为每个请求和响应都会给客户端一个新的 cookie。因此，TLS 中昂贵的公钥操作被分摊到大量请求中。
团队决定使用 Rust 来实现他们的服务，这与他们通常所选择的 Go 语言有所不同。正如作者们所指出的，他们决定使用 Rust 是因为“在响应 NTP 包的过程中垃圾收集暂停将会对精确性产生负面影响”。他们还指出，Rust 的内存安全性、不可为空性、线程安全性、不可变性和错误处理的特性是他们做出选择时的主要考虑因素。
随着这个版本的发布，CloudFlare 已经将他们的时间服务添加到公共 NTP 池中。NTP 池是一个由志愿者维护的服务，它在世界范围内提供 NTP 服务器。然而，他们注意到 NTS 在池模型中不能很好地运行。为了获得最佳的安全性，CloudFlare 建议启用 NTS 并使用 time.cloudflare.com 或其他支持 NTS 的服务器。
CFNTS 服务已经基于 2-Clause BSD 许可证开源。CloudFlare 希望他们的解决方案能够让更多的客户在未来支持 NTS。目前，他们正在积极地寻求对代码库的贡献。
原文链接：
CloudFlare Releases Open Source Implementation of Network Time Security Protocol
评论