This is what puzzles me - while time drift does occur, it tends to be in the form of minor errors which build up over time; large jumps are relatively rare. You'd think the mechanism described in the article would have a failsafe ensuring that only minor time recalibrations are performed.

It kind of depends. There's a lot of poor clocks at boot up time, but a continuously running host usually doesn't get too off, too quickly; I've seen some things, but even at 10% fast/slow, you don't have to jump days unless you're checking infrequently.

On the other hand, with virtualization, who knows how long it's really been between clock ticks. Let's say someone suspends a VM for a couple months and then unsuspends it; hopefully the clock is synchronized, but maybe it isn't, and you do need to jump ahead.

I thought I saw in the article that there are failsafes, but the allowed range is still pretty broad. But reporting is going to tend to be dominated by larger values, because smalller jumps are less likely to be noticed or more likely to be considered an accidental change.

Every VM software I've ever used automatically syncs the guest OS's clock to the host OS's clock. I've never used VMs in a server context, but do servers not do this too? It seems like the logical solution here.

I've certainly had issues with time sync in the past, and Windows has a wide range of deployment, so I would imagine they can't rely on it.

There are a lot of machines out there with a dead battery on the real time clock. Every time they boot, the time is miles out and at some system-determined zero point.

Imagine one could make an approximate clock that does not rely on batteries or similar things that can expire. How close would it need to be to the actual time to be useful? Does it have to be within a day, or could it be within a week or a month?

It's already discussed in the article -- because to determine that weather.gov connection is sound and not hacked, you first need to check its certificate expiration date. Chicken/Egg problem.

Why not let the user at least give an estimate for the current time & date. Should be close enough for certificate validation.

Yes, that gets annoying fast for said user, but a good incentive to eg fix the bios battery.

Imagine there is no user, and there are thousands of machines

Just have those machines randomly ask one another for the time. Because of the Wisdom of Crowds the time will eventually be right.

/ sarcasm

Fair point. Another reason I don't want to manage thousands of Windows machines. Or even one for that matter.

That's the point, if you can't trust the connection, stop trying to come up with more complicated ways to use the untrustable connection and accept that there is no safe way to update time.

Ok, so the system should fail to boot, right?

If for some reason an invalid time causes boot failure? Sure. There are some instrumented devices I work with that will alarm and cease operation if they lose their serial connection to a satellite clock, but those are few and far between.

But since the vast majority of them do not fail in that matter if the normal, configured methods of determining time aren't working, using TLS parameters that have been deliberately randomized by standard for like what, a decade now?, can not possibly be a more straightforward failure mode than logging errors and waiting for operator input.

If it's that critically important, embed a fixed signature for a set of known time sources and query those as a last resort. Microsoft certainly has the resources to set up a few to do this the much more obvious and predictable way.

That means your server could not serve HTTPS traffic at all, because you need valid timestamp for that.

> ...if it has a network...

But that network is not trusted.

Imagine this: You boot a machine for the first time, and the system clock tells you it's January 1, 1970. You might know when your OS was built, so you could maybe hard-code some sanity checks there, but you basically don't know what the date is.

You want to communicate securely with weather.gov? Sure, you can do that over SSL/TLS. You send it a list of cipher suites and SSL/TLS versions you can use, the weather.gov server selects a cipher and version, and sends you their certificate. It's valid from Jun 2023 to Jun 2024, signed by a DigiCert TLS RSA SHA256 2020 CA1 certificate valid Apr 2021 to Jun 2024, which is itself signed by the Digicert root global CA encoded into your OS's root certificate store, valid Nov 2006 to Sun, Apr 2031.

Wait a second. Or maybe 1.7 billion seconds. Are any of those certificates valid? Do you want to let the attacker set the date back to when a revoked, potentially leaked Trustico or Symantec private certificate was valid?

You don't have a secure network if you don't know what time it is.

Man it's like you and the other respondent want to be helpful but didn't read the next sentence after that bit of hyperbole.

If all available time sources are not trustable and none of the existing answers make sense, do not try to set the clock! Coming up with more complicated ways to use untrustable data is not an improvement.

Why can't it just ask the human to provide it, either in the welcome UI or in a setup script? That's how we've set up computers for many milliseconds.

because every developer has been told to never trust user input, and to sanitize the hell out of it.

There are public users and owner users. Specifically, you don't trust input from public users. You absolutely should trust input from owner users, or if you won't by default for some reason, you absolutely should give them the option to do so. Primarily, you should be giving them the choice as to what their system will do when it cannot reliably determine the actual time.

The alternative is to pretend that you can somehow divine a 'projected secure time.' Just, the gall to even write a sentence like that.

If your goal is to phase out local accounts and force microsoft.com logins as part of the computer setup, being able to trust your certificates seems like a prerequisite to being able to trust your users. And the correct time is a prerequisite to trusting your certificates.

This makes no sense..? If the admin wants to change the clock to something else and make their certs invalid, they can always do so. It's just for getting an initial handshake, and then after that NTP should keep working (at least until the next reset with a dead CMOS battery).

There's no way for the server to accurately determine the client's hardware clock, barring some sort of user-hostile hardware clock with a nuclear battery or hardened GPS or radio time receiver or something.

>'projected secure time.'

It's 5 o'clock somewhere!

It’s 1970-01-01T00:00:00Z somewhere

But the user input thing is not the rule, its a specific case of the more general rule regarding external data generally.

It definitely applies even more to the data it is trusting in this case.

If I understood the article correctly, this misfeature is for the rare case in which the server reboots after a power loss and the real-time-clock battery on the motherboard is dead, which can happen long after the initial setup of the server.

This is a hardware failure. The server should report to the domain controller a malfunction (by assuming it's certificate is valid) and then give up.

But this isn't just impacting machines at first boot. This is enabled in an on-going fashion.

The point isn't restricted to first boot. Lots of systems forget the time when they power cycle because of bad batteries or other trouble.

I mean, at that point the system should go to the IT group and be fixed.

The article says:

> Because Secure Time Seeding used SSL certificates Windows already stored locally, it could ensure that the machine was securely connected to the remote server. The mechanism, Microsoft engineers wrote, “helped us to break the cyclical dependency between client system time and security keys, including SSL certificates.”

But in that case, why does the Windows time service connect to a random server running OpenSSL instead of a trusted server under Microsoft's control like time.microsoft.com (or whatever)?

>instead of a trusted server under Microsoft's control like time.microsoft.com (or whatever)?

"Golly it's getting expensive hosting 100 billion random requests per year, lets let someone else shoulder the problem".

While this might not be it, we've seen plenty of other providers really screw up with time like this. I believe it was Linksys years ago just pointed their NTP as someone elses NTP servers and flooded them out.

Not all PCs are on the internet or have access to time.microsoft.com

> You don't have a secure network if you don't know what time it is

Yes, that's a very good reason not to trust the network to tell you what time it is.

Unfortunately, Windows, because it doesn't trust the network in the broad sense, relies on specific and known-to-be-unreliable SSL handshake data on the network to reset the clock.

> I can't imagine the sequence of horrible decisions that led to doing this.

My guess is that it was created because of Windows Phone 10. But it's not a feature I'd like even on my phone.

That seems far-fetched considering that afaik all cell networks provide time syncing

Cell networks provide some kind of time syncing... But accurate time syncing is less common than you'd think :)