2 ms·

Not precise, but for example if it's been over a day since the last time update, i start getting errors on various sites, including virtually every site behind

Not precise, but for example if it's been over a day since the last time update, i start getting errors on various sites, including virtually every site behind cloudflare. (assuming you're referring to the initial issue I mentioned). One of the setups that gives me issues is machines that are resumed from a historical snapshot and start doing things immediately, if the NTP date hasn't been updated since the last snapshot you start getting issues (despite snapshots being updated after every daily run). Most sites won't break (especially with a 24h window, although longer always have issues), but enough sites change their certs so frequently now, it's a constant issue. Even with a 10 year cert, if you access at the right time you'll have issues, the difference now is it isn't a once in a 10 year event, but once in every few days some times. Perhaps if TLS clients requesting a time update to the OS was a standardized thing and if NTP client daemons supported that method it would be a lot less painful?

akerl_ 10mo ago
If you’re drifting enough in 24 hours to affect cert trust, something wonky is up with the system.
- notepad0x90 10mo ago
  in my case, it's more of a case of "the system still thinks it's yesterday, until the ntp daemon updates the time a minute or five after resuming". Being behind by a day wasn't a huge deal before these really short cert life spans.
  - akerl_ 10mo ago
    This isn't something I've seen; are you running systems w/o an onboard RTC, or with ntpdate doing periodic update, etc etc? The closest I've gotten to this would be something like a Raspberry Pi, but even then NTP is pretty snappy as soon as there's network access, and until there's network access I'm not hitting any TLS certs.
    - notepad0x90 10mo ago
      Windows is the fastest from my testing, even then there is about a minute or so immediately after restoration where i get TLS errors on some sites. Honestly, I just wish that browsers used NTP directly and used that instead of the system time. If the CA/B wants to go this direction, maybe this will be a good enhancement to make it more tenable?
      - Dylan16807 10mo ago
        A system being an entire day off after suspend is hopelessly broken and we shouldn't expect browsers to fix it with their own time sources. Let's encrypt issues certificates with "notBefore" set an hour in the past to compensate for incorrect clocks. An hour is plenty of compensation.
        notepad0x90 10mo ago
        I think perhaps I'm doing a poor job at explaining the specific issue I encounter regularly, but if a system has been offline for a day, it will be askew by a day. Unless you're assuming a hardware clock that's on battery power is always available, and that the time/ntp daemon checks that and updates the clock fast enough. My use case isn't unique, if you have an embedded device, I'm sure there are even more stringent limitations. Is there really that big of a difference if the notBefore is a day instead of an hour, or even a week? Perhaps when shortening notAfter, notBefore should be increased.
        akerl_ 10mo ago
        The overwhelming majority of consumer laptops/desktops/etc today have a RTC so that yes, there's a battery keeping a RTC chip awake that keeps the clock reasonably correct after it's been powered off / hibernating / etc.
        notepad0x90 10mo ago
        You're totally right, but how much is the very small minority? What irks me slightly is that this is the type of thinking I typically see from companies like Google, where only 0.1% of users will be affected by a change, but 0.1% of a billion is 1 million people. I'm not saying I disagree with you, perhaps I'm the only person who might be affected, in which case who cares. But LetsEncrypt is a critical service provider at this point, they shouldn't calculate impact like a commercial entity that can ignore people due to lack of revenue implications. How unreasonable would I be if I expected TLS client clock precision to be part of the TLS spec, and such changes should require a version bump? That's probably extreme, but how can we ensure stability and reliability when these systems billions use change? Is the CA/B making decisions for everyone, even the minority? Do browser vendors care if some IoT device stops working?

akerl_ 10mo ago

If you’re drifting enough in 24 hours to affect cert trust, something wonky is up with the system.

notepad0x90 10mo ago
in my case, it's more of a case of "the system still thinks it's yesterday, until the ntp daemon updates the time a minute or five after resuming". Being behind by a day wasn't a huge deal before these really short cert life spans.
- akerl_ 10mo ago
  This isn't something I've seen; are you running systems w/o an onboard RTC, or with ntpdate doing periodic update, etc etc? The closest I've gotten to this would be something like a Raspberry Pi, but even then NTP is pretty snappy as soon as there's network access, and until there's network access I'm not hitting any TLS certs.
  - notepad0x90 10mo ago
    Windows is the fastest from my testing, even then there is about a minute or so immediately after restoration where i get TLS errors on some sites. Honestly, I just wish that browsers used NTP directly and used that instead of the system time. If the CA/B wants to go this direction, maybe this will be a good enhancement to make it more tenable?
    - Dylan16807 10mo ago
      A system being an entire day off after suspend is hopelessly broken and we shouldn't expect browsers to fix it with their own time sources. Let's encrypt issues certificates with "notBefore" set an hour in the past to compensate for incorrect clocks. An hour is plenty of compensation.
      - notepad0x90 10mo ago
        I think perhaps I'm doing a poor job at explaining the specific issue I encounter regularly, but if a system has been offline for a day, it will be askew by a day. Unless you're assuming a hardware clock that's on battery power is always available, and that the time/ntp daemon checks that and updates the clock fast enough. My use case isn't unique, if you have an embedded device, I'm sure there are even more stringent limitations. Is there really that big of a difference if the notBefore is a day instead of an hour, or even a week? Perhaps when shortening notAfter, notBefore should be increased.
        akerl_ 10mo ago
        The overwhelming majority of consumer laptops/desktops/etc today have a RTC so that yes, there's a battery keeping a RTC chip awake that keeps the clock reasonably correct after it's been powered off / hibernating / etc.
        notepad0x90 10mo ago
        You're totally right, but how much is the very small minority? What irks me slightly is that this is the type of thinking I typically see from companies like Google, where only 0.1% of users will be affected by a change, but 0.1% of a billion is 1 million people. I'm not saying I disagree with you, perhaps I'm the only person who might be affected, in which case who cares. But LetsEncrypt is a critical service provider at this point, they shouldn't calculate impact like a commercial entity that can ignore people due to lack of revenue implications. How unreasonable would I be if I expected TLS client clock precision to be part of the TLS spec, and such changes should require a version bump? That's probably extreme, but how can we ensure stability and reliability when these systems billions use change? Is the CA/B making decisions for everyone, even the minority? Do browser vendors care if some IoT device stops working?