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)。
NTS 过程的第一阶段
在第二阶段,客户端现在可以安全地与协商过的 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
评论