4 ms·

> ...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

> ...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 ago
But this isn't just impacting machines at first boot. This is enabled in an on-going fashion.
- Arnavion 3y ago
  The point isn't restricted to first boot. Lots of systems forget the time when they power cycle because of bad batteries or other trouble.
  - pixl97 3y ago
    I mean, at that point the system should go to the IT group and be fixed.
yetanotherloss 3y ago
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.
solardev 3y ago
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.
- dylan604 3y ago
  because every developer has been told to never trust user input, and to sanitize the hell out of it.
  - dragonwriter 3y ago
    But the user input thing is not the rule, its a specific case of the more general rule regarding external data generally. It definitely applies even more to the data it is trusting in this case.
  - akira2501 3y ago
    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.
    - bob-09 3y ago
      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.
      - solardev 3y ago
        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.
cpeterso 3y ago
The article says: > 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)?
- pixl97 3y ago
  >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.
- X-Cubed 3y ago
  Not all PCs are on the internet or have access to time.microsoft.com
dragonwriter 3y ago
> 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.
deleted 3y ago
[deleted]

jmholla 3y ago

But this isn't just impacting machines at first boot. This is enabled in an on-going fashion.

Arnavion 3y ago
The point isn't restricted to first boot. Lots of systems forget the time when they power cycle because of bad batteries or other trouble.
- pixl97 3y ago
  I mean, at that point the system should go to the IT group and be fixed.

yetanotherloss 3y ago

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.

solardev 3y ago

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.

dylan604 3y ago
because every developer has been told to never trust user input, and to sanitize the hell out of it.
- dragonwriter 3y ago
  But the user input thing is not the rule, its a specific case of the more general rule regarding external data generally. It definitely applies even more to the data it is trusting in this case.
- akira2501 3y ago
  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.
  - bob-09 3y ago
    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.
    - solardev 3y ago
      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.

cpeterso 3y ago

The article says: > 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)?

pixl97 3y ago
>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.
X-Cubed 3y ago
Not all PCs are on the internet or have access to time.microsoft.com

dragonwriter 3y ago

> 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.

deleted 3y ago

[deleted]