31–40 of 169 posts
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?
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.
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, someti…
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 the…
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.
Earlier quoted context omitted.
Openbsd does an https (with expiry checks disabled) GET to google.com (or another server) and uses the Date header in the response.
If it's assuming that it can make an internet connection, why does it do that rather than NTP?
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 the…
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.
Yes, that gets annoying fast for said user, but a good incentive to eg fix the bios battery.
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.
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.
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 the…
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.
Earlier quoted context omitted.
If it's assuming that it can make an internet connection, why does it do that rather than NTP?
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.
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.
Earlier quoted context omitted.
Openbsd does an https (with expiry checks disabled) GET to google.com (or another server) and uses the Date header in the response.
If it's assuming that it can make an internet connection, why does it do that rather than NTP?