6 ms·
I can't imagine the sequence of horrible decisions that led to doing this. Like, why would the time service ever want to depend on all this insanity when if it
by yetanotherloss 3y ago
I can't imagine the sequence of horrible decisions that led to doing this. Like, why would the time service ever want to depend on all this insanity when if it has a network and everything else is bizarro world, just like scrape the time and date text from weather.gov.
Or just accept that absent NTP, w32time maybe just shouldn't try to set the clock to whatever a circus clown tells it?
This sort of reminds me how there is a buried registry setting to tell w32time to not place the firmware clock at very high stratum in the time sources list which also is just a giant WTF in how those two behaviors were decided on.
- Varriount 3y agoThis 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.
- toast0 3y agoIt 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.
- Wowfunhappy 3y agoEvery 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.
- toast0 3y agoI'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.
- HPsquared 3y agoThere 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.
- magicalhippo 3y agoImagine 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?
- deepsun 3y agoIt'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.
- yetanotherloss 3y agoThat'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.
- deepsun 3y agoOk, so the system should fail to boot, right?
- yetanotherloss 3y agoIf 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.
- oskarw85 3y agoThat means your server could not serve HTTPS traffic at all, because you need valid timestamp for that.
- ragebol 3y agoWhy 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.
- LeifCarrotson 3y ago> ...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.
- jmholla 3y agoBut this isn't just impacting machines at first boot. This is enabled in an on-going fashion.
- yetanotherloss 3y agoMan 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.
- simendsjo 3y ago> 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.