• Windows Secure Time Seeding, should you disable it?

    Home » Forums » AskWoody support » Windows » Windows 10 » Questions: Win10 » Windows Secure Time Seeding, should you disable it?

    • This topic has 4 replies, 5 voices, and was last updated 9 months ago by TM.
    Author
    Topic
    #2582211

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

    What do you think of this bug?

    TLDR: Windows 10 has a feature called Secure Time which is on by default. It correlates time stamp metadata from SSL packets and matches them against time from the DCs. It processes these various times by means of black magic and sets the system clock accordingly. This feature has the potential to flip out and set the system time to a random time in the past. The flip out MIGHT be caused by issues with SSL traffic.

     

    Experts recommend disabling it.

    Simen said he believes the STS design is based on a fundamental misinterpretation of the TLS specification. Microsoft’s description of STS acknowledges that some SSL implementations don’t put the current system time of the server in the ServerUnixTime field at all. Instead, these implementations—most notably the widely used OpenSSL code library starting in 2014—populate the field with random values. Microsoft’s description goes on to say, “We have observed that most servers provide a fairly accurate value in this field and the rest provide random values.”

    “The false assumption is that most SSL implementations return the server time,” Simen said. “This was probably true in a Microsoft-only ecosystem back when they implemented it, but at that time [when STS was introduced], OpenSSL was already sending random data instead.”

     

    Ryan Ries, whose LinkedIn profile indicates he is a senior Windows escalation engineer at Microsoft: “Hey people,” he wrote. “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.” When someone asked him why, Ries responded, “Because it’s just a matter of time—*wink*—before it bites you in the butt.”

    1 user thanked author for this post.
    Viewing 2 reply threads
    Author
    Replies
    • #2582245

      So what is the solution?

      Should users disable STS?

      It can be done: https://www.thewindowsclub.com/secure-time-seeding-windows-10

      I’d be a bit reluctant to do so on the basis of one article (but one can find discussions on it by smart people in other places)…

      Advice?

    • #2582273

      For those running Windows 10 Pro or Enterprise (with an Admin-level account access on workstations), and who don’t like to “get their hands dirty” by poking around the registry, the same disablement can be accomplished from within the local machine’s Group Policy editor.

      As to whether or not one should disable the STS “feature” (some would argue that it’s a bug instead), it’s up to each person to decide based upon exactly what the individual computer is (or group of computers are) used for and the specific data that would be rendered inaccessible by the STS malfunction described within the original article.

      If lack of access to said data is intolerable for even a small amount of time, then disable STS. If in an enterprise environment, perform testing of the disablement’s effects before deploying to the enterprise, to say the least.

      Per MS’s own admission and the statements from affected users, this is a very random event so one never knows when (or even if) it will happen.

    • #2582326

      What do you think of this bug?

      It apparently only affects environments with multiple domain controllers bickering amongst themselves.

      If you’re a home/small business user in a Workgroup or single domain controller environment then IMO it’s a non-issue.

      Hope this helps…

      3 users thanked author for this post.
      • #2698407

        This is nothing to do with “domain controllers bickering among themselves”. It is a problem because the “Shady Time Seeding” feature supersedes NTP time (even one being synched perfectly well, either standalone or in a domain hierarchy) if it detects a bad sample from whatever poorly-developed algorithm it’s using to detect time from a protocol never intended for purpose.

        So, when your well-maintained DC jumps time several months into the future and back again, that has an impact on any accounts with the misfortune of authenticating during this interval. And any (important?) services that may be running under the security context of these accounts.

        For consumer devices where you don’t care about your system time, that may indeed be no big.

        For an AD environment, or anything using time-sensitive auth methods (i.e. Kerberos et al), this can and does cause issues. (Don’t) ask me how I know. As well as being slipped in with minimal documentation, it is enabled by default even if the system is configured with a good NTP time source or is in a domain. It does not have any features as built into NTP such as “spike watch interval” (so it discards bad samples it might happen to get over a short interval) nor a min or max interval where it can cause the system to “correct” its time. Such as 42 days into the future, as a not-random example.

        It should be disabled with extreme prejudice on DCs and servers in an AD environment. As for client machines, I feel like it should be disabled there too. Your personal device, your call.

    Viewing 2 reply threads
    Reply To: Windows Secure Time Seeding, should you disable it?

    You can use BBCodes to format your content.
    Your account can't use all available BBCodes, they will be stripped before saving.

    Your information: