What could be the cause of those jumps? Ars Technica journalists did a little research, and found that it might be linked to the Secure Time Seeding feature. In this post I explain how this feature seems to work, and what can be done to prevent such unexpected jumps.
What is Secure Time Seeding?
Secure Time Seeding (STS) was added to Windows 10 in 2015. The feature is intended to correct discrepancies between the time set in the system and the actual time – primarily when a computer’s battery feeding the internal real-time clock dies and the time settings have nothing in common with reality. Most importantly, STS is able to correct the system time without accessing the current-time servers.
But why is such a correction of time discrepancies even needed? Oddly enough, for security. Typically, client-server data exchange (including system connection to the internet time servers) is protected with SSL/TLS encryption protocols. To establish such a connection with the server, the client first needs to verify its digital certificate, and these certificates have a certain validity period. Therefore, if the time in the system is set with a significant error, the certificate may be considered expired, and a secure connection won’t be established.
So a vicious circle appears: in order to find out the current time, the computer needs to know the current time. It doesn’t have to be perfectly accurate; the approximate time can work too. But the greater the difference between the system time and the actual time, the greater the chance the certificate will get flagged as expired.
STS introduces (at least in its developers’ minds) a way for the system to automatically identify and correct major discrepancies, even when a secure connection cannot be established with any server. This is achieved by using current timestamps and digital-certificate expiry dates contained in the data sent by the servers to the client during the initial establishment of a secure connection (the SSL and TLS handshakes).
The exact algorithm of STS is unknown. But the general idea is that Windows pulls data from the SSL handshake and uses it to compute a reliable range for the current time and assign it a probability. As new data becomes available, the range is updated, and the probability can gradually increase. When it reaches a certain threshold, STS decides to change the system time to the median time from the range it deems reliable. In theory, such precision should suffice to establish a secure connection, connect to a current time server, and get the precise time.
Why you should disable Secure Time Seeding
The main problem is that the feature is enabled in Windows 10 by default and operates regardless of whether the computer’s built-in clock has ever been out of sync. As a result, STS can reset the time at any moment when Microsoft’s secret algorithm decides that there are enough signs that the clock is telling the wrong time and needs fixing.
The reason for such malfunctions in Secure Time Seeding isn’t fully understood. One suggested cause is the significant rise in popularity of SSL/TLS implementations that send an incorrect timestamp during the handshake. The chief suspect here is the frequently used OpenSSL library (which, instead of the current server time, puts random values in the timestamp).
Moreover, this bug can also occur in server versions of the operating system: Windows Server 2016, Windows Server 2019, and Windows Server 2022. And while for regular computer users the issue is little more than a nuisance, for servers it can be catastrophic, since their correct operation often relies on the time being accurate.
There’s an unofficial piece of advice on this from a senior Microsoft technical support official for Active Directory Domain Controller Administrators:
Disabling Secure Time Seeding in Windows
To disable STS, locate the following key in the Windows registry:
Find the UtilizeSslTimeData value and set it to 0.
Alternatively, you can run the following command as an administrator in the Windows command prompt (CMD):
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData /t REG_DWORD /d 0 /f
After changing the value, you need to reboot the system. If this is difficult or impossible, you can force the update with this command:
W32tm.exe /config /update
That done, the STS feature will stop bugging you. Now all that remains is to ensure that the system clock always stays accurate. On this point, the Ars Technica article gives a couple of helpful tips for server administrators.