Windows安全时间播种会将时钟重置为偏离正确时间几个月或几年

几个月前，挪威数据中心的一名工程师遇到了一些令人困惑的错误，导致Windows服务器突然将其系统时钟重置为未来55天。该工程师依靠服务器来维护一个路由表，当手机号码从一个运营商转移到另一个运营商时，路由表会实时跟踪手机号码。八周的跳跃带来了可怕的后果，因为它导致尚未转移的号码被列为已经转移，而已经转移的号码被报告为待定。

“使用这些更新的路由表，许多人无法拨打电话，因为我们没有正确的状态！”这位工程师在一封电子邮件中写道，他要求只透露自己的名字Simen。“我们会将呼入和呼出的电话转给错误的接线员！这意味着，例如，孩子无法联系到他们的父母，反之亦然。”

引人注目的问题
去年8月，Simen遇到了类似的错误，当时一台运行Windows Server 2019的机器将其时钟重置为2023年1月，然后在不久后又将其改回。对神秘重置原因的故障排除受到了阻碍，因为工程师直到事件日志被清除后才发现它。55天的更新跳跃，在运行Windows Server 2016的机器上，促使他再次寻找原因，这一次，他找到了。

罪魁祸首是Windows中一个鲜为人知的功能，即安全时间播种。微软介绍2016年的计时功能是确保系统时钟准确的一种方式。时钟设置错误的Windows系统可能会导致灾难性的错误，如无法正确解析数字证书中的时间戳，或者过早、过晚或不按规定顺序执行作业。微软表示，安全时间播种是对电池供电的机载设备故障的对冲，这些设备旨在即使在机器断电时也能保持准确的时间。

“您可能会问，为什么设备不通过网络向最近的时间服务器询问当前时间？”微软工程师写道。由于设备无法通过网络安全地通信，因此它也无法通过网络安全地获取时间，除非您选择忽略网络安全，或者至少通过设置例外在网络上打几个洞

为了避免出现安全异常，安全时间播种根据机器与远程服务器进行的SSL握手中的数据来设置时间。每当两台设备使用安全套接字层协议进行连接时，就会发生这种握手，安全套接字层协议是一种提供加密HTTPS会话的机制(也称为传输层安全性).因为安全时间播种(在本文的其余部分缩写为STS)使用已经存储在本地的SSL证书，所以它可以确保机器安全地连接到远程服务器。微软工程师写道，该机制“帮助我们打破了客户端系统时间和安全密钥(包括SSL证书)之间的循环依赖。”

Simen不是唯一一个在关键任务环境中遇到Windows系统时钟疯狂和自发波动的人。去年的某个时候，另一位名叫肯的工程师开始看到类似的时间漂移。它们被限制在两到三台服务器上，每隔几个月就会发生一次。有时，时钟时间会跳几个星期。其他时候，时间变化到2159年。

“受此影响的服务器呈指数级增长，”肯在一封电子邮件中写道。“总的来说，在5，000台服务器中，我们有大约20台服务器(虚拟机)遇到过这种情况。因此，这不是一个巨大的数额，但它是相当可观的，尤其是考虑到它所造成的损害。它通常发生在数据库服务器上。当数据库服务器在时间上跳跃时，它会造成严重破坏，只要服务器在时间上有如此巨大的偏移，备份也不会运行。对于我们的客户来说，这一点至关重要。”

西蒙和肯都要求只透露他们的名字，因为他们没有得到雇主的授权在记录中发言，他们很快发现，自2016年以来，工程师和管理员一直在报告相同的时间重置。

例如，在2017年，一个系统管理员论坛中的Reddit用户据报告的用户为一所大学管理的一些Windows 10机器报告了不准确的时间，在某些情况下，过去多达31个小时。Reddit用户最终发现时间更改与中的Windows注册表项相关HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\SecureTimeLimits。额外的调查显示，时间变化也与一些人试图访问该大学网站时报告该网站使用的有效SSL证书无效的错误有关。管理员得出以下结论:

TLDR: Windows
10有一个名为安全时间的功能，默认情况下是开启的。它将来自SSL数据包的时间戳元数据相关联，并将它们与来自DCs的时间进行匹配。它通过黑魔法处理这些不同的时间，并相应地设置系统时钟。此功能可能会将系统时间设置为过去的任意时间。这种变化可能是由SSL流量问题引起的。

人们报告相同行为的其他例子——例如，这里和这里—追溯到2016年，STS推出后不久。最近关于有害的STS引起的时间变化的报道有这里, 这里，以及这里.

一名Reddit用户写道:“我们遇到了一个令人窒息的问题，一些生产系统的时间提前了17个小时。”“如果你已经玩了一个多星期，你就会知道这会造成多大的破坏。”

STS入门
为了确定当前时间，STS提取SSL握手中包含的一组元数据。具体来说，这些数据是:

• 服务器运行时间，一种日期和时间表示形式，显示自1970年1月1日00:00:00 UTC以来经过的秒数
• 从远程服务器的SSL证书获得的加密签名数据，显示该证书是否已被称为在线证书状态协议.

微软工程师表示，他们使用ServerUnixTime数据“假设它有些准确”，但在同一句话中继续承认它“也可能不正确”为了防止STS根据单个不同步的远程服务器提供的数据重置系统时钟，STS随机建立与多个服务器的SSL连接，以获得可靠的当前时间范围。然后，该机制将ServerUnixTime与OCSP有效期合并，以产生最小的可能时间范围，并为其分配置信度得分。当分数达到足够高的阈值时，Windows会将数据分类为STSHC，即高可信度安全时间种子的缩写。然后，STSHC用于监控系统时钟的“总误差”并纠正它们。

尽管STS内置了检查和平衡来确保它提供准确的时间估计，但时间跳跃表明该功能有时会进行几天、几周、几个月甚至几年的胡乱猜测。

“在这一点上，我们不完全确定为什么安全时间播种会这样做，”肯在一封电子邮件中写道。“看上去如此随意，很难理解。微软在试图追踪这件事上也没有真正有所帮助。我已经发送了日志和信息，但他们没有真正跟进。他们似乎对结案更感兴趣。”

Ken发送的日志看起来像下面两张截图中显示的那样。他们捕捉了STS改变时间前后发生的系统事件。第一幅图像中选择的行显示了STS根据SSL握手数据计算的正确时间的界限，以及用于证实它的试探法。

所选行正上方的“预计安全时间”条目显示，Windows估计当前日期为2023年10月20日，比系统时钟中显示的时间晚了四个多月。STS随后更改系统时钟，以匹配错误预测的安全时间，如“目标系统时间”所示

第二个图像显示了一个类似的场景，其中STS将日期从2023年6月10日更改为2023年7月5日。

与此同时，西蒙说，他也向微软的多个小组报告了时间重置。当报告微软的问题时反馈中心他说，今年5月，他没有收到公司的回复。然后他通过Microsoft安全响应中心六月。该呈件作为“非MSRC案件”结案，没有详细说明。

然后，该工程师联系了专门从事微软云安全的第三方作为中介。中介转发了微软的响应，建议当服务器通过接收到可靠的计时时，关闭STS网络时间协议.

“不幸的是，这一建议并没有公开，它仍然远远不足以阻止错误设计的功能继续在世界各地肆虐，”西蒙在一封电子邮件中写道。

警告:STS会“咬你的屁股”

西蒙说，他认为STS设计是基于对TLS规范的根本性误解。微软的STS的描述承认有些SSL实现根本不把服务器的当前系统时间放在ServerUnixTime字段中。相反，这些实现——最著名的是从2014年开始广泛使用的OpenSSL代码库——用随机值填充字段。微软的描述继续说，“我们观察到，大多数服务器在这个领域提供相当准确的值，其余的提供随机值。”

“错误的假设是大多数SSL实现返回服务器时间，”Simen说。“这可能在他们实现它时只有微软的生态系统中是正确的，但是在那个时候(当STS被引入时)，OpenSSL已经是发送随机数据相反。"

虽然官方的微软谈话要点淡化STS的不可靠性，瑞安里斯，他的LinkedIn个人资料表明他是微软的高级Windows升级工程师，但当讨论STS去年在社交媒体上。