sim*_*sjo 5 windows time-synchronization
这看起来与Windows Server 2022 时间服务跳跃到未来是同一问题。我还在 Microsoft（反馈中心）添加了针对该问题的支持票： https: //aka.ms/AAkwnpl
由于系统时钟对于正确工作的软件至关重要，并且可能是最核心的共享可变状态，因此这个问题对我们的系统和与我们通信的每个人都造成了严重破坏，并一直波及关键基础设施。
我们于 2022 年 8 月在 2019 年的服务器上首次注意到这一点。时钟原定为 2023 年 1 月，但后来自行修正。不幸的是，这是在日志被清除一段时间后发现的，因此我们无法进一步调试它。
但上个月，我们再次体验了它，这次是在 2016 年的服务器上。时钟被设置为未来 55 天。
15 秒后，时间服务注意到时钟与我们的域控制器不同，并且它必须将时钟调回 -4454176 秒。它会后退，因为它大于 4294967295。
第一次更改后 15 分钟，时钟再次设置，这次倒退到未来的 12 小时 26 分 43 秒。
第二次更改后 15 秒，计时服务注意到时钟已关闭，这次修正了它，因为它在合理的窗口内。
三周后，同样的事情在同一台服务器上再次发生，只是细节有所不同。与此同时，服务器已重新启动并更新了新的每月更新。
我们使用 VMWare，配置了两个物理硬件时钟。我们有两个配置为使用 pool.ntp.org 的域控制器——可能应该移动到我们自己的 stratum 0 硬件，尽管它可能与我们的问题无关。
在一些外部专家的帮助下，我们几乎排除了错误配置、手动干预（错误、安全漏洞或不忠诚的员工）和硬件问题，并且留下了“奇怪的 Windows 错误”。
不幸的是，2016 年并没有包含与这些事件相关的太多细节，因此很难进一步调试。2019+ 包含更多信息。
Windows Server 2022 时间服务中的 @chris1out跳转到未来对于未在域中注册的服务器也存在同样的问题，因此我们可以排除域控制器。它还使用标准时间服务器而不是 pool.ntp.org。这意味着我们也可以排除这两者。这几乎留下了时间服务中的错误作为可能的原因。这个服务器故障问题是我们能够找到的唯一有记录的事件。
更新：Ars Technica 撰写了一篇关于此问题功能的文章：https://arstechnica.com/security/2023/08/windows-feature-that-resets-system-clocks-based-on-random-data-is-wreaking -浩劫/
TL;DR：我们找到了最可能的根本原因：W32time 安全时间播种，它查看 SSL 握手标头中的旧“时间”值，该值在较新的 SSL 实现中是随机的，将其解释为正确的时间，并设置时钟因此。
可以通过设置 UtilizeSSLTimeData 注册表项来关闭它：
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData /t REG_DWORD /d 0 /f
并且可以指示 w3tm 重新读取其配置：W32tm.exe /config /update
答案较长...
Microsoft 于 2015 年 11 月发布了一项名为“安全时间播种”的功能，该功能包含在 Windows Server 2016+ 中并默认打开。
它试图缓解系统没有电源驱动系统时钟（例如电源故障和 CMOS 电池损坏）从而导致启动时间完全错误、无法与其他来源安全地通信以可靠地获取正确时间的问题。时间。
在传出 SSL 握手期间，它会查看“ServerUnixTime”（可能
gmt_unix_time在规范中）。
TLS 1.2 规范规定如下（重点是我的）：
根据发送者的内部时钟，采用标准 UNIX 32 位格式的当前时间和日期（自 1970 年 1 月 1 日午夜开始的秒数，UTC，忽略闰秒）。 基本 TLS 协议不需要正确设置时钟；更高级别或应用程序协议可能会定义额外的要求。请注意，由于历史原因，数据元素使用 GMT 命名，即当前全球时间基准 UTC 的前身。
微软最初的博客在他们的帖子中说了以下内容（强调我的）：
ServerUnixTime 应该是服务器上的当前系统时间，但也可以通过某些 SSL 实现将其设置为随机值。我们观察到，大多数服务器在此字段中提供相当准确的值，其余服务器提供随机值。我们使用此数据字段时假设它有些准确，但也可能不正确。
这表明他们误解了规范，并且他们的实现是在错误的假设下设计和运行的。当世界仍在使用较旧且更不安全的实现时，它们的实现可能运行良好，但随着越来越多的服务器正在更新，前提是完全错误的。
至少他们不信任单一来源，但由于提供时间的来源较少，而使用随机值的来源较多，因此 4 个字节相似到足以混淆他们的算法可能只是时间问题。
我们采取的方法是不信任来自单独服务器的数据，无论服务器将自己标识为谁。我们依靠来自多个服务器的证实信息来得出有关当前时间的共同事实。
他们进一步描述他们正在使用统计方法来查看何时可以将随机字节解释为正确的时间（强调我的）：
来自 ServerUnixTime 和 OCSP 有效期的信息被合并，以生成尽可能小的可靠时间范围值以及置信度分数。当置信度分数足够高时，该数据就变成了信息。
该gmt_unix_time字段于 2013 年 9 月在 TLS 邮件列表上进行了讨论，比 Microsoft 发布此功能早了两年，该功能于 2013 年 10 月在 OpenSSL 中实现，并于 2014 年 1 月发布。
commit 2016265dfbab162ec30718b5e7480add42598158
Author: Nick Mathewson <nickm@torproject.org>
Date: Sun Oct 20 15:03:24 2013 -0700
Do not include a timestamp in the Client/ServerHello Random field.
Instead, send random bytes, unless SSL_SEND_{CLIENT,SERVER}RANDOM_MODE
is set.
This is a forward-port of commits:
4af793036f6ef4f0a1078e5d7155426a98d50e37
f4c93b46edb51da71f09eda99e83eaf193a33c08
3da721dac9382c48812c8eba455528fd59af2eef
2583270191a8b27eed303c03ece1da97b9b69fd3
While the gmt_unix_time record was added in an ostensible attempt to
mitigate the dangers of a bad RNG, its presence leaks the host's view
of the current time in the clear. This minor leak can help
fingerprint TLS instances across networks and protocols... and what's
worse, it's doubtful thet the gmt_unix_time record does any good at
all for its intended purpose, since:
* It's quite possible to open two TLS connections in one second.
* If the PRNG output is prone to repeat itself, ephemeral
handshakes (and who knows what else besides) are broken.
commit 2927791d77ddaef687e92b1779e0bff89bdc279f
Author: Nick Mathewson <nickm@torproject.org>
Date: Sun Oct 20 15:08:58 2013 -0700
Fix another gmt_unix_time case in server_random
### Major changes between OpenSSL 1.0.1e and OpenSSL 1.0.1f [6 Jan 2014]
* Don't include gmt_unix_time in TLS server and client random values
* (.. unrelated changes ..)
u/zanatwo 于 2017 年 3 月发现了此问题，并在 r/sysadmin 上报告了该问题，但没有迹象表明 Microsoft 知道此问题，因为它仍然处于启用状态。
它于 2022 年 1 月被 u/Thranx 重新发现，并在 r/sysadmin 上进行了报道。
从今年年初开始，@chris1out 在 ServerFault 上再次发布。
正如我们和其他人所经历的那样，该问题的频率正在增加，可能是由于报告实际时间和随机值的服务器较少。这很可能会继续增加频率并影响更多用户。
系统时钟是系统上最重要的共享可变状态，将时间更改为截然不同的值的错误会对所有系统造成严重破坏，其影响远远超出其发生的单个服务器。毫无疑问，这是我遇到过的最严重的错误/错误功能，微软需要尽快禁用此功能。
与 Microsoft 联系很困难，因此如果您遇到同样的问题，请向 Microsoft 报告此问题。
非常感谢 @test-is-prod 分享他们的发现，并向我指出 /u/zanatwo 的 Reddit 帖子！
参考：