Informative article but it meanders about for way too long.
- In some circumstances, Windows resets its clock based on the ServerUnixTime field of incoming TLS handshakes, for reasons that are not completely clear
- OpenSSL puts random numbers in ServerUnixTime
- Problem!
- Disable via
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\SecureTimeLimits
See? That didn’t take long.
So does that mean one needs to run NTP as well as the domain-based time sync, for when the donation based one fails?
Seems weird. I wonder why they’re so cagey about it
Their official advice is to disable STS when using NTP.
As for the explanation, I think it was just an example of bad decisions compounding on themselves.
- Oh no, it’s difficult to sync time because the secure communication layer doesn’t work when our time is already out of sync. That’s okay, we’ll use a totally other dubious mechanism instead of fixing that.
- Oh no, the dubious mechanism is giving us bad results sometimes. That’s okay, we’ll introduce weird heuristics to attempt the impossible problem of determining whether the dubious mechanism’s output is trustworthy.
- Oh no, the heuristic fails sometimes. That’s okay, “We agree that the overall direction of technology with the adaption of TLS v1.3 and other developments in this area could make Secure Time Seeding decreasingly effective over time, but we are not aware of any bugs arising from their use. This technology direction also makes heuristic calculation of time using SSL/TLS far less attractive when compared to deterministic, secure time synchronization.”
Right. Instead of setting up their own secure date and time server or ensuring devices can establish a secure channel to a time server regardless of the circumstances, they decided to use SSL certificates to securely get the date and time? Which is an issue because the unix time stamp can have anything in it. Not only that, but it’s enabled by default, meaning that most server hosts won’t think to disable it until it starts causing problems. Right. And no one thought that this would be an issue?
I’m not a professional, but if I were to take a guess as to why the bug is becoming more common, it’d be that it’s probably self-perpetuating. One server gets the wrong unix time and flips out. Then, while IT is trying to fix the server, another server just kinda yoinks the SSL certificate from the bugged server to check the unix time. That server now has the wrong time too. However, this server doesn’t have anything time-sensitive on it (or at least nothing urgently affected by the time bug), and the error corrects itself by the time anyone notices. In the meantime, another server has borrowed that server’s SSL certificate, again, to check the time, and gets the wrong time as a result. Throw in the fact that there may be some people who, either out of maliciousness or for some niche application, have their systems intentionally misreporting the unix time, and voila!
My favorite bit of the article is this (also not a professional)
“The engineer then tapped a third party specializing in Microsoft cloud security to act as an intermediary. The intermediary relayed a response from Microsoft recommending STS be turned off when the server receives reliable timekeeping through the Network Time Protocol.”
Microsoft is bad enough that they know it’s an issue and basically said “we aren’t going to fix it, and we won’t tell you directly or make the issue known to avoid problems, but just turn it off”
Honestly should be their official motto. They did the same thing with a vulnerability installaware addressed for them last year.
If windows doesn’t work the way it should, just turn it off (forever, and install Linux).
They already have that. time.windows.com
If it ain’t broke, fix it until it is, I guess.
If you have a critical system, don’t run it on Windows. Maybe one of these days they might ship it with sane defaults instead of weird shit like this, or security settings violating their own best practice documents.
Nuh uh. Microsoft is so advanced thar their Quantum™ based technology allows servers to time travel.
2023 and businesses still be using windows server??
They are very common. You’re not thinking of small businesses and their needs. Sure, a linux server works wonders for a large corporation where it’s doing a lot of back end stuff but you’ll be hard pressed to find a business that flies solely on linux.
