101–110 of 169 posts
Earlier quoted context omitted.
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.
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…
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.
Earlier quoted context omitted.
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 d…
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.
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.
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…
"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.
Let me guess, time isn't set, so dnssec is broken, so ntp servers won't reolve, so you can't set the time?
So lame, ntp servers shouldn't be using dnssec.
Earlier quoted context omitted.
Nice spot. Perhaps something that is meant to add a delta to a timestamp accidentally adds 2 timestamps together.
How is the hardware clock connected? It it is something serial it could be an offset by 1 bit.
Earlier quoted context omitted.
> ...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 cip…
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.
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.
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 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 tha…
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…
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!
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 day…