{"id":21623,"date":"2023-09-07T07:25:54","date_gmt":"2023-09-07T11:25:54","guid":{"rendered":"https:\/\/me-en.kaspersky.com\/blog\/?p=21623"},"modified":"2023-09-19T17:38:32","modified_gmt":"2023-09-19T13:38:32","slug":"windows-system-time-sudden-changes","status":"publish","type":"post","link":"https:\/\/me-en.kaspersky.com\/blog\/windows-system-time-sudden-changes\/21623\/","title":{"rendered":"Wrong system time and insecure Secure Time Seeding\u2028"},"content":{"rendered":"

Every now and then, Windows 10 users and administrators wonder<\/a> why the time on their systems suddenly jumps by several weeks, months or even years (either forward<\/a> or backward<\/a>).<\/p>\n

What could be the cause of those jumps? Ars Technica journalists did a little research<\/a>, 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.<\/p>\n

What is Secure Time Seeding?<\/h2>\n

Secure Time Seeding (STS)<\/a><\/p>\n

was added to Windows\u00a010 in 2015. The feature is intended to correct discrepancies between the time set in the system and the actual time \u2013 primarily when a computer\u2019s battery feeding the internal real-time clock<\/a> 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.<\/p>\n

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<\/a>) 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\u2019t be established.<\/p>\n

So a vicious circle appears: in order to find out the current time, the computer needs to know the current time. It doesn\u2019t 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.<\/p>\n

STS introduces (at least in its developers\u2019 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).<\/p>\n

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.<\/p>\n

Why you should disable Secure Time Seeding<\/h2>\n

The main problem is that the feature is enabled in Windows\u00a010 by default and operates regardless of whether the computer\u2019s built-in clock has ever been out of sync. As a result, STS can reset the time at any moment when Microsoft\u2019s secret algorithm decides that there are enough signs that the clock is telling the wrong time and needs fixing.<\/p>\n

The reason for such malfunctions in Secure Time Seeding isn\u2019t 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).<\/p>\n

Moreover, this bug can also occur in server versions of the operating system: Windows\u00a0Server\u00a02016, Windows\u00a0Server\u00a02019, and Windows\u00a0Server\u00a02022. 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.<\/p>\n

There\u2019s an unofficial piece of advice<\/a> on this from a senior Microsoft technical support official for Active Directory Domain Controller Administrators:
\n\u2028
\n<\/p>

\u201cHey people, if you manage Active Directory domain controllers, I want to give you some UNOFFICIAL advice that is solely my personal opinion: Disable Secure Time Seeding for w32time on your DCs.\u201d<\/div>
\n\u2028
\n
\"Unofficial<\/a>

Unofficial advice from a Senior Windows Escalation Engineer: disable Secure Time Seeding<\/p><\/div>\n

Disabling Secure Time Seeding in Windows<\/h2>\n

\nTo disable STS, locate the following key in the Windows registry:<\/p>\n

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeConfig<\/code><\/p>\n

Find the UtilizeSslTimeData value and set it to 0.
\n\u2028
\n<\/p>

\"Disabling<\/a>

Disabling Secure Time Seeding in the Windows registry<\/p><\/div>\n

Alternatively, you can run the following command<\/a> as an administrator in the Windows command prompt (CMD):<\/p>\n

reg add HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesw32timeConfig \/v UtilizeSslTimeData \/t REG_DWORD \/d 0 \/f<\/code><\/p>\n

After changing the value, you need to reboot the system. If this is difficult or impossible, you can force the update with this command:<\/p>\n

W32tm.exe \/config \/update<\/code><\/p>\n

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<\/a> gives a couple of helpful tips for server administrators.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

Why the Windows system time can suddenly change, and how to stop it from happening.<\/p>\n","protected":false},"author":2726,"featured_media":21625,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1318,1916,1917],"tags":[97,560,268,113],"class_list":{"0":"post-21623","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-security-2","11":"tag-ssl","12":"tag-vulnerabilities","13":"tag-windows"},"hreflang":[{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/windows-system-time-sudden-changes\/21623\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/windows-system-time-sudden-changes\/26162\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/windows-system-time-sudden-changes\/28859\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/windows-system-time-sudden-changes\/26469\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/windows-system-time-sudden-changes\/26655\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/windows-system-time-sudden-changes\/29140\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/windows-system-time-sudden-changes\/35996\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/windows-system-time-sudden-changes\/48956\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/windows-system-time-sudden-changes\/20952\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/windows-system-time-sudden-changes\/21736\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/windows-system-time-sudden-changes\/30440\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/windows-system-time-sudden-changes\/26743\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/windows-system-time-sudden-changes\/32471\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/windows-system-time-sudden-changes\/32125\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/me-en.kaspersky.com\/blog\/tag\/windows\/","name":"windows"},"_links":{"self":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/21623","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/2726"}],"replies":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=21623"}],"version-history":[{"count":4,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/21623\/revisions"}],"predecessor-version":[{"id":21684,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/21623\/revisions\/21684"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/21625"}],"wp:attachment":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=21623"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=21623"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=21623"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}