解决Windows系统时间跳转55天后程序出现Bug问题

一直以来，操作系统的「时间、日期、时区」，是让很多程序员在开发程序时比较敏感与特别关注的问题。

还记得即将步入 2000 年的“千年虫”（Year 2000 Problem，简称“Y2K”）事件。由于早期的计算机配置比较低，那时为了节省空间就把年份只用后两位数表示，如 1999 就表示为 99，导致新千年时电脑把 2000 年认为是 1900 年，出现 Bug，进而引发各种各样的系统功能紊乱甚至崩溃。

2012 年，有用户发现低内核版 Linux 开启 NTP 服务器会遇到闰秒 Bug，导致服务器重启。

2016 年，很多网友“作了一把”，将 iPhone 的日期设置到 1970 年 1 月 1 日，无意中触发系统 Bug，一时间导致 iPhone 重启失败，手机直接变板砖。

就在近日，一个新的关于时间 Bug 出现在 Windows 系统中。据 Ars Technica 报道，有一位挪威数据中心的工程师 Simen 遇到了一个令人费解的时间 Bug， 它会导致 Windows Server 突然将系统时钟重置到未来 55 天。

时间 Bug 带来的混乱

事实上，这并不是 Simen 第一次遇到这个问题。

在去年 8 月，Simen 曾遇到过类似的错误，当时一台运行 Windows Server 2019 的机器将时钟重置到了 2023 年 1 月，但过了没多久又自动跳回来了。

后来，直到事件日志被清除后才发现这一问题，但那时无法分析具体是什么原因导致的。

现在，他又在一台运行 Windows Server 2016 的机器上遇到了这个问题。

对于普通用户而言，时间的错乱带来的短暂影响也许可以忽略不计。但是对于工程师而言，却是一个让人崩溃的存在。

Simen 的主要工作是在 Windows Server 维护一个路由表（存储在联网计算机中的电子表格（文件）或类数据库），这个路由表实时跟踪手机号码从一个运营商转到另一个运营商的过程。

当服务器出现时间 Bug 时，系统时钟跳到八周后，这就带来一个不可估量的后果，譬如，此前尚未迁移的号码被列入已经迁移、已经转移的号码被列为待处理状态，整个都乱掉了。

无独有偶

本来以为这只是一个特例，但是搜索一下，网络上遇到这个问题的工程师不在少数。

去年，有一位名叫 Ken 的工程师也发现了类似的“时间跳跃”现象，当时在 2-3 台服务器上，时钟时不时会跳跃到几周后，甚至有一次直接跳到了 2159 年。

据 Ars Technica 披露，Ken 在一封邮件中写道：“受此影响的服务器呈指数增长，越来越多。在 5000 台服务器（虚拟机）中，我们总共有 20 台左右的服务器（虚拟机）遇到过这种情况。这种情况通常发生在数据库服务器上。当数据库服务器在时间上发生跳跃时，就会造成严重破坏，只要服务器在时间上有如此大的偏移，备份也就无法运行。对于我们的客户来说，这一点至关重要。”

除了 Simen 和 Ken 之外，追溯到 2017 年，一位 Reddit 用户 zanatwo 发帖称他在一所大学工作，某一天，其发现校园内的几台 Windows 10 计算机开始出现错误的时间。这些计算机上显示的时间 Bug 完全是随机的，在某些情况下，他的设备时间直接跳到了 31 个小时之前。

通过深入分析，当时 Reddit 用户发现，时间变化与 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\SecureTimeLimits 中的 Windows 注册表键相关。进一步的调查显示，当一些人试图访问大学网站时，这些错误报告称网站使用的有效 SSL 证书无效。

Windows 官方发布的功能惹了祸？

经过排查之后，以上几位工程师将罪魁祸首统一定位到了 Windows 上一个鲜为人知的功能—— Secure Time Seeding（简称 STS）中。

这是微软在 2016 年引入 Windows 的功能，主要作用就是在 Windows 设备无法通过安全连接与时间服务器通信的情况下，改进对正确时间的记录。简单来看，这也是设备在断电情况下也能保证准确的时间。默认情况下，这一功能在 Windows 系统及服务器下是打开的。

从工作原理来看，为确定当前时间，STS 会调用 SSL（Secure Sockets Layer）握手过程中包含的一组元数据。具体来说，这些数据包括：

ServerUnixTime，日期和时间表示法，显示自 1970 年 1 月 1 日 00:00:00 UTC 时起已过去的秒数。

从远程服务器 SSL 证书中获取的加密签名数据，显示该证书是否已根据所谓的 "在线证书状态协议 "机制被撤销。

在发布这一功能时，微软工程师在官方文档中写道，他们使用 ServerUnixTime 数据是 "假定它在一定程度上是准确的"，但在同一句话中又承认它 "也可能是不正确的"。

为了防止 STS 根据单个不同步远程服务器提供的数据重置系统时钟，STS 会随机穿插 SSL 连接到多个服务器，以得出当前时间的可靠范围。

然后，该机制会将 ServerUnixTime 与 OCSP（Online Certificate Status Protocol，在线证书状态协议 ）有效期合并，以产生尽可能小的时间范围，并为其分配置信度分数。

当分数达到足够高的阈值时，Windows 就会将数据归类为 STSHC（Secure Time Seed of High Confidence，高置信度安全时间种子）。然后，STSHC 用于监控系统时钟是否存在 "严重错误"，并对其进行纠正。

尽管 STS 内建了检查和平衡机制，以确保其提供准确的时间估计，但长期以来工程师遇到的“时间跳跃”事件表明，该功能有时会做出误差数天、数周、数月甚至数年的胡乱猜测。

在 Ars Technica 报道的文章中，其分享了来自工程师 Ken 遇到时间跳跃时的具体截图。

第一张图片中的选定行上方的 "预计安全时间 "条目显示，Windows 预计当前日期为 2023 年 10 月 20 日，比系统时钟显示的时间晚四个多月。然后，STS 会更改系统时钟，使其与"目标系统时间 "中显示的错误的预计安全时间相匹配。

第二张图片显示了类似的情况，其中 STS 将日期从 2023 年 6 月 10 日改为 2023 年 7 月 5 日。

在遇到这一问题后，Ken 和 Simen 都向微软进行了反馈，遗憾的是，他们并没有得到实质性的回应与解决方案。

微软工程师个人曾发出警告：主动关闭 STS 功能

那要问有没有解决方法，其实去年一位微软 Windows 高级工程师 Ryan Ries 发过推文提供过用户，其写到“大家好，如果你们管理 Active Directory 域控制器，我想给你们一些非官方的建议，这完全是我的个人意见：在您的 DC 上禁用 w32time 的 STS。”

当有网友进一步询问原因时，Ryan Ries 表示，「因为在它咬你的屁股之前，这只是一个时间问题」。

这也不禁让人好奇，连微软自家工程师都觉得这个功能有问题，为什么官方还有做保留。

就在众人存疑时，微软在给 Ars Technica 的一份声明中写道：

STS 功能是一种基于启发式的计时方法，在某些软件/固件/硬件计时失效的情况下也有助于校正系统时间。该功能已在所有默认 Windows 配置中默认启用，并已证明在默认配置中发挥了预期功能。

每次部署的时间分配都是独一无二的，客户通常会根据自己的特殊需求来配置机器。鉴于 "STS"的启发式性质以及客户可能使用的各种部署，我们提供了禁用该功能的选项，以满足客户的需求。我们的理解是，在客户遇到 STS 问题的部署中，很可能存在独特、专有、复杂的因素，而这些客户并不能从目前实施的这一功能中受益。在这些个别情况下，我们只能建议在部署中禁用该功能。

具体来看，要禁用 STS，可以在受影响的机器上设置一个注册表项。这是 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config 目录中的 UtilizeSslTimeData 密钥，其类型为 REG_DWORD。如果设置为 0，则停用 STS。如果设置为 1，则可以重新激活该功能。

STS 的异常，有没有解决方案？

截至目前，似乎除了关闭此功能之外，并没有太过合适的解决方案，因此，很多人对于微软的回应并不买账。在 HN 上，网友也展开了激烈的讨论，甚至有人吐槽：是时候应该买块手表来核对服务器上的时间了！

另外，有网友 @theqmann 分析认为，「这听起来像是一种统计方法，如果在给定时间内收到 N 个时间戳相似的数据包/连接，就会改变时钟。我可以看到这样一个问题：一台 Windows Server 每分钟全天候提供数千或数百万个 OpenSSL 数据包，而它恰好随机接收到 N 个数据包，这些数据包彼此非常接近，足以满足统计阈值的要求。通过随机跳转，连续跳转十多次时间都是有可能的」。

@jmuguy 则表示：

在我做 IT 人员的这些年里，Windows Time 是我处理过的最烦人的事情之一。注册和取消注册 w32time，尝试不同的 NTP 服务器。试图弄明白为什么域系统无法从 DC 获取时间。这总让人感觉很......愚蠢。在设备上设置正确的时间肯定没那么复杂。事实证明，并不复杂，除非你使用的是 Windows 系统。有点讽刺的是，如今我唯一需要处理的 Windows 系统就是我的游戏电脑。它拒绝与 time.windows.com 同步。

除了 Windows 系统之外，还有人称在 Linux 中也遇到了同样的问题。

@nicolaslem 表示：

我的 Linux 笔记本电脑有时也会遇到类似的问题，把电脑从睡眠中唤醒时，时间会跳到 2077 年。我猜这是硬件故障，因为它并不经常发生，但一旦发生就会造成很大影响。我无法想象在生产服务器上发生类似情况会有多大影响。

你是否遇到过类似的问题？

参考：

https://arstechnica.com/security/2023/08/windows-feature-that-resets-system-clocks-based-on-random-data-is-wreaking-havoc/

https://news.ycombinator.com/item?id=37151220

https://www.reddit.com/r/sysadmin/comments/61o8p0/system_time_jumping_back_on_windows_10_caused_by/