3 ms·

I know this is a good thing, but I've struggled a lot on systems that don't have good/reliable NTP time updates. Also, at some point in the lifetime graph, you

I know this is a good thing, but I've struggled a lot on systems that don't have good/reliable NTP time updates. Also, at some point in the lifetime graph, you start getting diminishing returns. There aren't many scenarios where you get your private keys stolen, but the bad guys couldn't maintain access for more than a couple of weeks. In my humble opinion, if this is the direction the CA/B and other self-appointed leaders want to go, it is time to rethink the way PKI works. We should maybe stop thinking of LetsEncrypt as a CA but it (and similar services) can function as more of a real-time trust facilitators? If all they're checking for is server control, then maybe a near-real-time protocol to validate that, issue a cert, and have the webserver use that immediately is ideal? Lots of things need to change for this to work of course, but it is practical. Not so long ago, very short DNS TTL's were met with similar apprehension. Perhaps the "cert expiry" should be tied to the DNS TTL. With the server renewing much more frequently (e.g.: If the TTL is 1 hour, the server will renew every 15 minutes). Point being, the current system of doing things might not be the best place to experiment with low expiry lifetimes, but new ways of doing things that can make this work could be engineered.

tptacek 10mo ago
Why do you need precise timing to make this work?
- notepad0x90 10mo ago
  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.
        10mo ago
grayhatter 10mo ago
> I know this is a good thing, strongly disagree. Increasing complexity in a system rarely makes it more robust. It primarily makes it more expensive.

tptacek 10mo ago

Why do you need precise timing to make this work?

notepad0x90 10mo ago
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.
        10mo ago

grayhatter 10mo ago

> I know this is a good thing, strongly disagree. Increasing complexity in a system rarely makes it more robust. It primarily makes it more expensive.