4 ms·

I agree with the sentiment that cert expiry is a frequent cause of outages. I think short lived certs and automated cert management are a better fix versus cert

I agree with the sentiment that cert expiry is a frequent cause of outages. I think short lived certs and automated cert management are a better fix versus certs that never expire (for that issue). If you don't have an expiry then you'd need to keep certificate revocations around forever, so your CRL grows without bound. Currently the certificate revocation list can remove expired certificates as clients won't use them. There's also lots of clients that don't check CRLs. Those clients would be forever vulnerable to a stolen certificate if we removed expiry. Imagine if you inherited the infrastructure for a company where the previous admin created certs, lost track of them, and used questionable methods for securing them. I believe you'd struggle to find and revoke every previously issued certificate. The expiry ensures that gets cleaned up, eventually. I don't have a good solution to the Nokia Symbian problem. I suspect if the device only supports SHA-1 then there are other unpatched security issues. Does anyone know if that's the case? If so, this seems more like a support and patching issue.

usr1106 6y ago
> I don't have a good solution to the Nokia Symbian problem. I told that mostly as an anecdote. I don't think a solution is really expected. The devices I referred to (made 2005 - 2007) worked rather well for about 10 years. I guess that's a satisfactory achievement.
thayne 6y ago
> There's also lots of clients that don't check CRL This is in part due to the difficulty of doing so. On linux at least there is generally not a central location for CRLs, or anything to keep them up to date. Each application is responsible for maintinging CRLs it cares about itself. And then there is the fact that a full set of CRLs is pretty big. OCSP fixes some of that, at the cost of more latency during the TLS handshake. OCSP stapling is probably the best existing solution, but I don't think it is widespread enough that you can rely on it yet.
- bawolff 6y ago
  OCSP stapling always felt a little hacky to me. It feels like just having super short lived certificates but with extra steps. Why not just have super short lived certificates instesd?
  - thayne 6y ago
    That's fair.
- sciurus 6y ago
  If you haven't seen it already, check out https://blog.mozilla.org/security/2020/01/09/crlite-part-1-all-web-pki-revocations-compressed/ https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a... (Disclaimer: I work for Mozilla and have helped with the rollout of this)
  - thayne 6y ago
    That is certainly an interesting project, I wish it success, and it may very well improve things in the future. However, it looks like currently it is only experimentally used in firefox and isn't really easy to use in other applications. And even if there was a readily available library for consuming crlite files, there is still the problem of keeping the local crlite filter up to date and if you want to use different trust anchors than firefox, you would need to have the infrastructure to generate your own crlite filters periodically.
sverhagen 6y ago
That was a great clarification, but wouldn't those admins also possibly have put far out expiration dates, to make things "easier" on them.
- AlphaSite 6y ago
  I think most browsers typically enforce a maximum duration.

usr1106 6y ago

> I don't have a good solution to the Nokia Symbian problem. I told that mostly as an anecdote. I don't think a solution is really expected. The devices I referred to (made 2005 - 2007) worked rather well for about 10 years. I guess that's a satisfactory achievement.

thayne 6y ago

> There's also lots of clients that don't check CRL This is in part due to the difficulty of doing so. On linux at least there is generally not a central location for CRLs, or anything to keep them up to date. Each application is responsible for maintinging CRLs it cares about itself. And then there is the fact that a full set of CRLs is pretty big. OCSP fixes some of that, at the cost of more latency during the TLS handshake. OCSP stapling is probably the best existing solution, but I don't think it is widespread enough that you can rely on it yet.

bawolff 6y ago
OCSP stapling always felt a little hacky to me. It feels like just having super short lived certificates but with extra steps. Why not just have super short lived certificates instesd?
- thayne 6y ago
  That's fair.
sciurus 6y ago
If you haven't seen it already, check out https://blog.mozilla.org/security/2020/01/09/crlite-part-1-all-web-pki-revocations-compressed/ https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a... (Disclaimer: I work for Mozilla and have helped with the rollout of this)
- thayne 6y ago
  That is certainly an interesting project, I wish it success, and it may very well improve things in the future. However, it looks like currently it is only experimentally used in firefox and isn't really easy to use in other applications. And even if there was a readily available library for consuming crlite files, there is still the problem of keeping the local crlite filter up to date and if you want to use different trust anchors than firefox, you would need to have the infrastructure to generate your own crlite filters periodically.

sverhagen 6y ago

That was a great clarification, but wouldn't those admins also possibly have put far out expiration dates, to make things "easier" on them.

AlphaSite 6y ago
I think most browsers typically enforce a maximum duration.