I wonder if you could use this 'feature' to exploit a system?
Set up a bunch of servers all over the internet with innocuous web pages. Get all of them to include in their SSL headers the exact identical timestamp of July 5th 1998.
Then get the user to connect to all those domains (eg. with a page with a bunch of iframes).
The Secure Time service will see that lots of remote servers all agree with high confidence that the date is July 5th 1998. So the system clock gets set to then.
Then you use a leaked yet expired cert (or maybe one signed with a broken algorithm) to impersonate an update server or steal valuable cookies/tokens.
Expired certs typically fall out the back of revocation systems too - so it really is just the expiry date/time that protects against their use.
That's not just plausible but probably needs a CVE and then MS will have to act.
I can feel an experiment coming on: Mint an OpenSSL based CA and use it to generate 200 certs for randomly generated CNs. The script could write out a zone file and web server vhost configs. Pop the CA cert in a Win PC/Server trust store. "Fix" the time on the web server. AutoIT could be used to poke a browser at each vhost or an iframe monstrosity.
I have yet to see this snag myself but it sounds like an MS style screw up. Excellent engineering fucked up by one wrong assumption which leads to a huge towering monstrosity. Sheer arrogance precludes a back down, MS ploughs on and then after a year or two, a fix is silently released and the victim shaming carries on for a little while longer. Meanwhile social.ms carries on advising sfc /scannow and then reinstalling the OS.
> advising sfc /scannow and then reinstalling the OS.
I really hate that. If there is some problem, properly diagnose it, figure out how it happened, and figure out how to change things so it can never happen to you or anyone else again.
Or you could just wipe all config and reinstall everything and hope it doesn't happen again!
My work Windows server VM boxen started off life largely as 2008 R2, one was 2008. They are all now mostly 2022 and converted to EFI with secure boot - some of them put up quite a fight. Not a large setup - three DCs - one in my home attic for DR, a File n Print n NPS n CA box, a Trellix (Nee McAfee) ePO and a few more bits n pieces.
sfc /scannow can fix issues but it is not a panacea and certainly not the first thing you should reach for. It sorts some aspects of .dll hell but that is an app thing and a complex one.
As you say, get the logs out and your stethoscope. Sadly most of us don't have access to source with Windows, so we rely on intuition, 30 years of experience and some really cunning search queries. Even though Google search is largely wank, a decent and carefully curated ublocklist can winnow out the worst rubbish.
Having said that, Outlook is totally damned when it comes to logs. Outlook trace logging is an Outlook programmers debugging tool only and of absolutely no use for a sysadmin. You literally fly blind with Outlook and are best off looking at Exchange logs instead. The Outlook devs are only interested in themselves and no one else. You do get CTRL - r click on Outlook icon to unlock the connectivity checker to give you absolutely no help apart from showing how bad things are. The autodiscovery checker is handy and I have fixed configuration issues with it.
Fiddler is a MitM proxy with knobs on. I don't deny it is rather handy. I use a lot of tools.
Wireshark simply listens. If you give it the private key for a TLS exchange it is able to decrypt the stream.
Fiddler makes changes to the stream - it turns a single stream into two streams with the Fiddler in the middle, Wireshark does not - per se - it just listens but because it will be a tap in a stream it will slightly affect that stream, unless you use a switch that can mirror ports - and that's what I do.
When it is your web server (int al) then you have access to the private key and then Wireshark's minimal touch is indicated. Otherwise Fiddler or similar (Squid and others for me) is indicated instead.
(I've used Fiddler for... ever, so I'm familiar with it)
The GP likely doesn't have the private key if they're using Outlook. As if they're using Outlook it is most likely with Exchange. And if they're using Exchange, it is most likely EXO. Hence, Fiddler as the appropriate recommendation for this portion of the thread.
If you have to resort to a proxy (fiddler) then you are making changes. You do not get to sample unblemished data. Perhaps that is OK for the snag/issue in question but may not be.
Port mirroring/SPAN/RSPAN is the only way to be an observer without affecting the traffic you are inspecting. Fiddler literally does a man in the middle attack.
If you don't have access to a private key for a TLS exchange and stream, then you cannot do quite a lot of diags.
In the end, Fiddler and the like might do the job but to really get close to the wire requires full knowledge and a much lighter touch. That will be a port SPAN/mirror and Wireshark and a private key.
TFA seems to only mention errors where the time is set to the future, which would probably indicate that Microsoft at least thought of this. Their responses seem to indicate that they also don't think that it's a security issue, which means they likely don't know of any _explicit_ way to exploit this.
It seems to me that it could still be used to bring down a windows server right around the time that you wanted to, which is still a potentially serious security concern.
At the very least you can can screw with Kerberos which requires a default of something like five mins time sync. That's a denial of service. Keep it up for long enough and the device will fall off AD as well.
If you're a big enough customer, and you contrive a way to rely on this bug, then you've hacked the Microsoft backwards compatibility commitment. They'll have to preserve the functionality in perpetuum.
Windows Time bullshit was one of the most annoying things I dealt with during my years as an IT guy. Registering and unregistering w32time, trying different NTP servers. Trying to figure out why domain systems werent getting their time from the DC. It always felt so... stupid. Surely having the correct time on a device isnt that complicated. Turns out, its not, unless you're on Windows. Somewhat ironic that these days the only Windows system I have to deal with is my gaming PC. It refuses to sync with time.windows.com.
It's probably still the case that Windows will consider the firmware clock more reliable than anything but a stratum 1 (direct gps/glonas/atomic) or maybe 2 time source which can result in truly bizarre behavior if the firmwar/hypervisor drifts too far from dozens of stratum 2 or 3 active directory servers. It logs no messages about this logic fork.
I don't recall the exact conditions that determine this but troubleshooting it is an exercise in thinking you're having a stroke.
I have a Windows work laptop that sometimes drifts up to 10 minutes off the correct time despite time/date settings saying it has synced every day. It won't even let me correct the time because of an enterprise policy requiring it to use network time. Then one day it will be back to the correct time and the drift cycle begins anew.
I find some humor in this being somewhat familiar with the history of clocks and watches. Forever the battle was making the most accurate time pieces possible, with wrist watches eventually reaching a few seconds per day variance before digital watches took over. And new we have something trillions of times more complicated and is performing worse
There are ways said to circumvent the enterprise policy on the autosync side, like unregistering win32tm or deleting all servers from the registry. No idea about setting the time though…
(A smarter time daemon like chrony would've kept track of the RTC drift.)
I decided a while ago that I was willing to sacrifice a few (and it's very few now - mostly just some anti-cheat using ones) games to just go Linux full time. I don't miss Windows one bit (well except Photoshop I guess :/) and I game a lot.
Unless you need the newest features, Photoshop runs surprisingly well under Wine - and I don't mean this in the usual "oh yea, Wine totally works" way where it's a huge pain to set up and is 90% luck, it actually runs with barely more glitches than on Windows (not zero, but it's Adobe software, so you can't expect much).
I use the art side more, which Krita is ok for and Darktable for bulk processing. It's mainly that most online guides, utils and demos are done in PS so harder to follow.
Unfortunately, for photography, Darktable really doesn't get close to Lightroom. Most of the tools are more clunky, the performance is worse (and Lightroom is already painfully slow) and most critically, the quality of the edits is significantly worse. Taking the same significantly under-exposed photo into both and boosting the exposure to roughly the same brightness produces results that are so wildly different in noise level and artefacts that you wouldn't believe they had the same input.
In 1996 I was supporting a small dialup operation, and one of our customers was having non-stop problems connecting via modem.
Their plant was 2 hours away, but I was driving past there to visit a friend, so I made arrangements to drop by and investigate.
For reasons unknown, most of their Windows desktops were configured to a year in the 21st century, probably 2096 instead of 1996 but it’s been a while. Wish I knew how they ended up that way, but I’m surprised dialup was the only thing they noticed that was broken.
A lot of shareware back then stopped working after a certain # of calendar days, which it used windows to figure out. So I always had my date set far in the future.
you're right--I think the trick must have been to set the computer date far in the future when installing the software, then return to the correct date for future executions.
Windows isn't the only thing with issues. Both ntpd and systemd-timesyncd can be very annoying if upstream servers send a bad stratum value, and the maintainence team of upstream is a bunch of morons taking weeks to fix it. You can't say "forcibly use IP w.x.y.z no matter what" to either of them.
That feature is simply insane. How did MS think this was a good idea?
To address the issue they were trying to address (what happens when a mission critical server's RTC malfunctions or the battery dies?), Windows should treat it no differently than any other hardware malfunction in a mission-critical server: raise an alarm so a system operator can take a look and address the issue.
> “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.”
> Here's something I wrote about removing a fingerprinting opportunity
from the current TLS protocol.
So the point is not that it was a bad idea, it is that MS didn't keep up with the world and didn't respond to requests from their customers to fix the problem.
But, their _starting position_ is that they can't trust the network
> “Since the device is not in a state to communicate securely over the network, it cannot obtain time securely over the network as well, unless you choose to ignore network security or at least punch some holes into it by making exceptions.”
So, because they can't trust the network, or the time, they instead choose to randomly trust some of the requests over the network.
But it's okay because they rely on the certificate from that request to report whether it has been revoked or not.
The point is that it was guaranteed behavior before the spec was changed. As an aside, I do find it amusing that the memo was co-authored by a Googler. Google has the best fingerprinting & tracking tech baked into their core products. I guess they don't want competition! :)
Yeah, when I read about SSL returning the server time I thought of fingerprinting, and I'm glad to see that it was removed. The reason giving for using it – PRNG completely broken – gave me a WTF moment, too. A broken PRNG is gonna cause a lot more trouble in SSL (TLS) than a non-random random field.
It really feels like someone's thought experiment that was cargo-culted into production. Timestamps are truthy to begin with, and mission-critical systems are designed to die and be reborn anew like the common Phoenix. Physical issues that might come up are addressed in the spec and logical issues stop everything they touch. At no point have I ever hoped that a third party would start pumping garbage into the problem.
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.
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.
> 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.
> 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.
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.
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.
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.
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.
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.
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.
I wonder if this feature might be “infectious”: if a handful of servers wind up with the wrong time, and start propagating that wrong time in their server handshakes, it might cause a cascade of other servers to reset their times too.
In any case, it seems like a poor solution especially given that random timestamps can occasionally look valid (they’re random!).
The problem they’re trying to solve seems to be to obtain a trustworthy timestamp in the presence of a potentially hostile network - one that could be presenting expired, cracked certificates for every connection to arbitrarily tamper with all SSL connections. It’s not a trivial problem, for sure, but resetting perfectly valid clocks using this algorithm seems like a strict downgrade….
Funny thing is that it does refuse to change the time when the delta is large. So it trusts these random bytes in the TLS handshake blindly, but when it gets the correct time from the time server some seconds later, it doesn't dare to change the time as the delta is too large!
Wow, we encountered a similar problem on one of our servers. We couldn't determine the cause. We set up an alarm to notify us when such a change occurs, and we've developed a procedure to handle the consequences. Great discovery!
God knows how windows machines keep time these days, except to say that they basically don't. WSL2 has not ever been able to keep time consistent between the host and VM. You can find the issue threads on gitlab going back years at this point.
A bit of a tangent, but this time-checking heuristic reminds me of the game "Halo 3: ODST".
The story takes place in a future African megacity before, during, and after an alien invasion. Part of the game's story is shown from an AI's perspective who controls the city's operations trying to evacuate the Human survivors.
Whenever the story is shown through the AI's perspective, you can see an overlay of the AI's working memory including which suburb's cameras are being monitored, the emotional state of the AI, and the current running timestamp.
Some of the aliens end up withdrawing from within the city by making an FTL jump which causes extreme localised time dilation.
Immediately afterwards, the timestamp in the AI's working memory is frozen because it's not sure what the exact timestamp is anymore, each system it connects to gives it a slightly different time depending on how close it was to the FTL event.
It guesses a likely time and uses that until sometime later it is able to reconnect with other unaffected human networks and resumes the correct timestamps.
This time heuristic was shown in the game, but also makes an appearance of sorts in the announcement trailer (seen in the bottom right): https://www.youtube.com/watch?v=WroxHMo6B_k
A better solution to secure bootstrapping of time would be NTP+NTS (RFC 8915) using self-signed certificates with unlimited time validity, which can be preloaded with the OS and updated via normal OS updates if the server key is compromised. They would probably need to run their own servers. There are some public NTS servers (e.g. Cloudflare and Netnod), but I have not seen any using long-term certificates specifically for this use case.
I sometimes experience a similar issue with my linux laptop where time jumps to the year 2077 when waking up from sleep. My guess is that it is a hardware glitch as it doesn't happen often, but when it does it is quite impactful.
One of the annoying consequences is that some parts of the system decide to clean up "old" data. Surely data that has been stale for 50 years can be deleted, right? I cannot imagine the impact of something similar happening on a production server.
If it's an x86 laptop, it will be compatible with the MC146818 chip found in the original IBM AT, and return the time in BCD format as yyyy/mm/dd hh/mm/ss.
While this Windows feature does sound quite bonkers as described, it is also baffling to me that the timekeeping on computers is such a mess; would it really be that difficult to have my multithousand dollar computer keep time at least as well as a dollar-store quartz watch? Have time already set in factory, and be correct to within few hours at least; enough to do networking and more accurate time syncing safely.
Your dollar-store quartz watch isn't on a worldwide network communicating with other watches where there needs to be an agreement on what time it is. The watch also expects you to notice when the time drifts and for you to correct it. That includes DST adjustments, leap second adjustments, and physically moving to different timezones.
Even when using an NTP server to set your time, network latencies have to be taken into account. Otherwise, if the request took 300ms round-trip and that weren't accounted for then your machine is already 300ms off from "official" time. Depending upon what you're doing, being that far off can be critical.
These are things your dollar-store quartz watch simply doesn't need to concern itself with.
> That includes DST adjustments, leap second adjustments, and physically moving to different timezones.
Does it? My system/bios time is in UTC. The timezone is not managed for me, when I travel I change it. DST and leap seconds are deltas you add to UNIX epoch. Tracking the number of ticks since epoch is a simpler task, much closer to what a quartz watch attempts to do on its own. Both fail when the battery does, of course.
If your end user facing application can't handle 300ms drift that seems like a bug in the application. Even stuff like TOTP generators let you apply a time delta correction and servers usually allow >1 minute drift.
I mean for SSL purposes, no that's not really needed that much. Micro seconds don't matter as certs typically expire on a monthly to yearly basis. And those that expire closer to monthly are typically updated on a regular basis.
If you have a critical need for leap second time you're typically using your own means of NTP and not Microsofts broken ass bullshit.
> If you have a critical need for leap second time you're typically using your own means of NTP and not Microsofts broken ass bullshit.
I love that statement! It reflects my 40 years experience in software - if you're doing something serious then don't use Microsoft's broken ass bullshit. I smile and remember Microsoft's origins as a gaming company. To this day that's what they're best for!
The problem of computer timekeeping lives on the margins. Your computer is probably more accurate than the quartz watch, but there's all sorts of ways that timekeeping can fail even on a system that's accurately counting time when on. Many of these have to do with early boot or unattended scenarios where trustworthy sources of time data are scarce or difficult to reach. e.g. maybe the motherboard clock chip is five months off because of a firmware bug or something, and this is a server so there's no user to notice the incorrect time and not having it set itself would cause catastrophic application failures somewhere else. Computer timekeeping is a comedy of errors.
Computers do do this. The problem is that some computers are quite old and the battery that keeps the real-time clock running has gone flat. That means if the computer is powered off it forgets what time it is.
If your quartz watch battery goes flat you replace it straight away because a watch with a flat battery is 100% useless. But if the battery on your motherboard goes flat you don't even notice, so why would you replace it? To a layperson, "my computer's time is always wrong" is not likely to be caused by a random flat battery that they didn't know existed.
Microsoft came up with this "Secure Time" system so that even computers with flat batteries would be able to work out what time it is, but obviously it is kind of weird and sometimes makes wrong decisions.
Fixing computers with a broken batteries sounds just about as smart as
"Microsoft came up with an internet boot image that allows your computers to boot windows even if the hard drive is dead without users realizing this is the case"
Honestly, when the battery dies, it's time to take it to the shop.
Timepieces last a decade on a shirt button sized battery. Surely you can afford a bit larger battery on a motherboard, probably even a rechargeable one, make the clock sufficiently autonomous from the rest of the system, and make the motherboard not boot when it doesn't have the battery, so you can leave it unattended for a while.
A decade is roughly the upper limit of specified battery shelf life for cheap batteries. Making the battery bigger doesn't really help much at that point where it's limited by shelf life, not capacity.
There are longer life batteries, but they're _expensive_, e.g. a Tadiran TL-4934, 1Ah, with a shelf life of 40 years will cost ~5$ in bulk.
The CR2032 on a PC motherboard does usually last for about a decade, and the BIOS (or, well, UEFI) will scream about the CMOS battery being dead when you boot it. It will not refuse to boot, but it will tell you that the battery is dead and/or that its settings are corrupt and alert you to change it.
Enter the temperature compensated crystal oscillator (TXCO). A few $ at most should get you one.
This shouldn't be overkill for a server dedicated to timekeeping on a large company network, right?
In a datacenter one could even go for a matchbox sized atomic clock. Last I checked (years ago) such a miracle device could be had for ~$1500.
Then: how often does atomic clock (or even TXCO) fail, in practice? My guess: only about as often as even the backup power fails.
Note that either should provide accurate timekeeping without even going outside a physical location. That is: without using 'random' NTP server on the internet, GPS or whatever.
I've got a GPS-disciplined Oven Controlled Crystal Oscillator (OCXO) hooked up to a raspberry Pi running Chrony on my home network. It provides a pretty good time source (and more importantly for me a pretty good 10MHz reference). There are rack-mount 1U NTP servers built for the purpose for about what you estimate.
Most atomic clocks will have 20+ year lifetimes. OCXOs age out a good bit faster, but they're rather cheap (<$200 for ones good enough to provide holdover for a GPS module). TCXOs don't age as quickly (they're not literally in an oven), I'm not sure how long they can be expected to last.
Two most underrated problems in software development are tracking (and timezones) and calendars. They both seem really simple on the surface, while in practice they’re a gigantic mess that takes enormous amount of work to get right.
TL:DR, the w32time service will sometimes try to bootstrap the clock with data from TLS handshakes. TLS 1.0-1.2 use a random value in Client Hello/Server Hello which was originaly specified as a uint32 gmt_unix_time plus 28 random bytes. It's better [1] to fill the whole structure with 32 bytes of random data (and TLS 1.3 specifies it without reference to time). If you interpret the random data as a unix time, sometimes you're going to get weird results. It's not clear to me what servers w32time probes to get these values, either.
I've seen other services that use https to bootstrap time in case other clocks are unavailable or suspect (or use a limited expiration certificate to authenticate!), it's a bit difficult because you have to ignore or postpone checking certificate expiration when validating the x.509 certificates, parse the http date header, and then presumably check that the date provided is within the time the certificates involved are valid.
I was baffled at what was happening after reading the article. Your TL;DR was perfect, and explained it very well in a single short paragraph. Thank you.
I always thought that it was a bad decision that Windows tracked time as local time. IMO they got it wrong right from the get-go. It made more sense to me to track time in an unambiguous manner(*) like seconds since midnight January 1. 1970 GMT and then convert to whatever representation is convenient locally.
(*) I suppose this does not work as well on Mars. I suspect that the time on the various extra-planetary vehicles is tied to earth time but would not work so well if Mars were ever colonized.
Hmm, so essentially it's sampling times from different servers it thinks are unlikely to be conspiring, and those times are not as reliable as expected.
Since it's fun to imagine (and then find flaws in proposals) here's an idea for y'all:
1. If the device reaches out to a dozen servers at different usually-trustable domains (e.g. microsoft.com, nist.gov) and they _all_ have "expired" certificates, that becomes a sign that My Local Time Is Unreliable. (Or that the machine is being booted up by an attacker who has connected it to a fake micro-internet.)
2. The Windows device contains a cert or public key which does not auto-expire based on clock-time, but is only replaced as a side-effect of OS patches. This cert/key exists for one specific purpose, allowing it to securely get a time from an MS time fallback server. Such a server would not normally be queried, and can have very relaxed performance/accuracy/uptime requirements. It could literally just be a GET call returning a epoch integer.
3. This way the client system can bootstrap up to something close-enough-to-current that the regular NTP process can be completed for a more-precise time.
Obviously this can fail if the attacker injects a fake cert/key into the machine... but at that point isn't it Game Over anyway? The same attacker could just put in their own certificate authority for any service.
It may not work for computers that are left unplugged and unpatched for a few years, but it sounds like the real issue are live servers, or ones that just suffered some power-supply hiccup.
I’ve used Linux on an embedded system which gets time/date via proprietary monitoring protocol. Seting Linux time/date isn’t instant, Linux will run an accelerated clock until it reaches the target time. This bizzare behaviour is a hack to fix apps/services which have too high delta time which cause other problems. Its frustrating for us since when we receive a clock update, our clocks can take hours to sync. Meanwhile our packet clocks are inaccurate. This only happens during testing (by gov regulators) and to pass the tests, we had to outsmart the way the system clock works when receiving a large date/time diff.
All of these work-arounds for unneeded hacks (like in the article) drives my temper way up. Just do the simple thing in kernel space or the OS level. No suprises.
NTP will step the clock instead of slewing it if the offset exceeds a threshold, your proprietary algorithm should do the same if the time to adjust the clock is too long. I don’t think it’s unreasonable for apps to assume that time is continuous and always moving forward, so slewing seems like a good solution to the problem of time synchronization, if you need instant synchronization you can always step the clock yourself.
Under ordinary conditions, the clock discipline gradually slews the clock to the correct time, so that the time is effectively continuous and never stepped forward or backward. If, due to extreme network congestion, an offset spike exceeds the step threshold, by default 128 ms, the spike is discarded. However, if offset spikes greater than the step threshold persist for an interval more than the stepout threshold, by default 300 s, the system clock is stepped to the correct time.
“You may ask—why doesn’t the device ask the nearest time server for the current time over the network?” Microsoft engineers wrote. “Since the device is not in a state to communicate securely over the network, it cannot obtain time securely over the network as well, unless you choose to ignore network security or at least punch some holes into it by making exceptions.”
Let me guess, time isn't set, so dnssec is broken, so ntp servers won't reolve, so you can't set the time?
Why not use all that STS cleverness to get a "rough" estimate of the current time, then use that estimate to securely connect to an NTP server and get the actual time?
Why even bother with all of the STS cleverness? The article suggests a perfectly good way to get a rough but trusted time stamp by… scraping it from a known good HTTP server.
Anyway, STS as described is an obviously broken protocol. It’s not clear to me that it is even capable of reliably getting a rough time.
My understanding was that they want to pull the time over a secure (TLS) connection only - but to establish a secure connection, they already have to have the time in advance. That kind of catch-22 would always appear, no matter whether the thing you want to connect to is an NTP or an HTTP server.
So far, it all makes sense. It stops making sense when their attempt at breaking the catch-22 seems to do so by in fact ditching the "secure connection" requirement, just doing so in an obfuscated manner.
I agree, if you already violate your own rule, you could have saved everyone a lot of hassle and just pull the time from a plaintext HTTP server.
But then you might just as well ask a plaintext NTP server and go back to where everything started...
I think the idea is that NTP is only supposed to work if your clock is close enough to correct, in order to prevent wackiness from ensuing due to sudden extreme jumps in the system time, presumably from a misconfiguration, compromised server, or whatever. I suppose you could just rely on an insecure NTP and force the date correction, but given that the default is not to do that and you have to force it, there’s probably some reason why you shouldn’t. So, if your goal is to get the accurate time over a secure connection, getting a “close enough” time over an insecure connection and confirming/adjusting the time over secure NTP doesn’t actually seem like the craziest way to do it.
I don’t really know why bootstrapping over HTTP then adjusting via secure NTP is better than bootstrapping via plaintext NTP then confirming with SSL enabled, but I guess it at least means two servers and protocols would have to be compromised.
Does anyone discuss the hypothesis that it’s a statistical bug in the implementation and that there’s some small but non-negligible probability that the servers see a pattern of random timestamps that convinces them of a false time? Because the would be my naive guess as to the cause.
How is a basic web application supposed to treat client time? In some of my systems, the server responds with its timestamp, the client records it's delta between itself and the server, and we use that delta as an offset into stuff like auth token refresh. My main PC has the incorrect timezone in its bios, so it's always 6hr in the future when I first log in..it's interesting to see what breaks. Rocket League for instance doesnt work at all. Starcraft 2 works fine. Windows was unable to sync itself in this situation for months, but has fixed itself lately so it can sync to the right time after a few minutes
In my opinion writing that Microsoft fucked up where clearly other software puts bogus data in timestamp fields is laughable. Shit goes in - shit goes out.
I think MS should improve implementation in two ways:
- ask known trusted sources (like their own servers) for SSL timestamp
- use that timestamp only internally (as opposed to system-wide) to acquire valid NTP timestamp
The point that Windows became less reliable than Linux Desktop happened last month.
Windows 7 is still more reliable, but with the updates being over, people are forced to upgrade.
But Windows 11 is less reliable than popular Linux Desktops. There might be an exception if you have NVIDIA, but I'd say less than a few percent of people have a video card.
Look, you can use (with some care) time from a Kerberos KDC for the domain/realm to which the host is joined if you like, but you can't use the time from random application servers!
The article doesn’t talk about a fix—scary. I know OpenBSD uses a similar SSL-based method for time keeping on startup, but I’ve never experienced an issue like this.
NTP is trivially MITM. Secure NTP is basically not deployed anywhere. Someone with a google.com cert that's valid other than expiration is probably google and probably has a working clock.
Sure, if you have such a dongle, and it has sufficient view of the sky. Adding a 'free' https based sanity check on top of NTP seems like a good balance of cost vs reward.
gps (and friends) is a nice way to get access to a very accurate timesource, but it's not always worth the cost.
Here's the PowerShell cmd to do so: Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config" -Name "UtilizeSslTimeData" -Type DWord -Value 0
Set up a bunch of servers all over the internet with innocuous web pages. Get all of them to include in their SSL headers the exact identical timestamp of July 5th 1998.
Then get the user to connect to all those domains (eg. with a page with a bunch of iframes).
The Secure Time service will see that lots of remote servers all agree with high confidence that the date is July 5th 1998. So the system clock gets set to then.
Then you use a leaked yet expired cert (or maybe one signed with a broken algorithm) to impersonate an update server or steal valuable cookies/tokens.
Expired certs typically fall out the back of revocation systems too - so it really is just the expiry date/time that protects against their use.