4 ms·

What is the point of shortening the life time to 45 days? Why not 60 seconds? That's way more secure. Everything is automated after all, so why risk compromise

by gethly 10mo ago

What is the point of shortening the life time to 45 days? Why not 60 seconds? That's way more secure. Everything is automated after all, so why risk compromised certificate for such a long period, like 45 days? Or how about we issue a new certificate per request? That should remove most of the risks.

shim__ 10mo ago
Could have just kept using OSCP stapling
- ekr____ 10mo ago
  Basically OCSP stapling (more specifically must-staple) is isomorphic to short-lived certificates.
- alwillis 10mo ago
  OSCP enables every website someone visits to be tracked; see https://news.ycombinator.com/item?id=46290033 https://news.ycombinator.com/item?id=46290033
  - SkiFire13 10mo ago
    OSCP stapling (which OP mentions) is supposed to fix that though.
jfindper 10mo ago
While I believe you're posting questions out of frustration rather than genuine curiosity, I think it's worth pointing out two things. One: most of the reasoning is available for reading. Lots of discussion was had. If you're actually curious, I would suggest starting with the CA/B mailing group. Some conversation is in the MDSP (Mozilla's dev-security-policy) archives as well. Two: it's good to remember that the competing interests in almost every security-related conversation is the balance between security and usability. Obviously, a 60-second lifetime is unusable. The goal is to get the overlap between secure and usable to be as big as possible.
- asah 10mo ago
  serious q: maybe not 60 sec, but why 45 days instead of ~1 day or even hours? at 45 days, it pretty much has to be automated.
  - ahoka 10mo ago
    They are not sadists, contrary to what others say in the comments.
    - jsheard 10mo ago
      Although for the benefit of masochists, they are going to offer 6 day certs as an option soon.
      - phasmantistes 10mo ago
        Yep, the "shortlived" (6-day) profile will be available to the general public later this week. But at this time we explicitly encourage only mature organizations with stable infrastructure and an oncall rotation to adopt that profile, as the risks associated with a renewal failing at the beginning of a holiday long weekend are just too high for many sites.
  - tetha 10mo ago
    Our internal CAs run 72 hour TTLs, because we figured "why not" 5-6 years ago, and now everyone is too stubborn to stop. You'd be surprised how much software is bad at handling certificates well. It ranges from old systems like libpq which just loads certs on connection creation to my knowledge, so it works, down to some JS or Java libraries that just read certs into main memory on startup and never deal with them again. Or other software folding a feature request like "reload certs on SIGHUP" with "oh, transparently do listen socket transfer between listener threads on SIGHUP", and the latter is hard and thus both never happen. 45 days is going to be a huge pain for legacy systems. Less than 2 weeks is a huge pain even with modern frameworks. Even Spring didn't do it right until a year or two ago and we had to keep in-house hacks around.
  - 10mo ago
benjiro 10mo ago
You know that the original idea was to drop it to 17 days?! And i think that is still on the books. To be honest, the issue is not the time frame, you can literally have certs being made every day. And there are plenty of ways to automated this. The issue is the CT log providers are going to go ape! Right now, we are at 24B certificates going back to around 2017 when they really started to grow. There are about 4.5B unique domains, if we reduce this to the amount of certs per domain, its about 2.3B domain certs we currently need. Now do 2.3B, x 8 renewals ... This is only about 18,4B new certs in CT logs per year. Given how popular LE is, we can assume that the actual growth is maybe 10B per year (those that still use 1 year or multi year + the tons of LE generated ones). Remember, i said the total going back to 2017 currently is now only 24B ... Yea, we are going to almost double the amount of certs in CT logs, every two years. And that assumes LE does not move to 17 days, because then i am sure we are doubling the current amount, each year. Good luck as a CT log provider... fyi, a typical certificate to store is about 4.5kb, we are talking 45TB of space needing per year, and 100TB+ if they really drop it down to 17 days. And we did not talk databases, traffic to the CT logs, etc... Its broken Jim ... Now imagine for fun, a daily cert, ... 1700TB per year in CT log storage? A new system will come from Google etc because its going to become unaffordable, even for those companies.
- nickf 10mo ago
  Where did you get 17 days from?
  - benjiro 10mo ago
    There was talking going on in one of the CA/Browser Forum regarding certificate expirations, and how they looked at potentially 17 days. The 45 days was a compromise, but the whole 17 days was never removed from the table, and was still considered as a future option.
    - nickf 10mo ago
      Honestly don't recall discussing 17 days, but I could be wrong. 47 days was a 'compromise' in that it's a step-down over a few years rather than a single big-bang event dropping from 397->90/47/less.

by gethly 10mo ago

shim__ 10mo ago

Could have just kept using OSCP stapling

ekr____ 10mo ago
Basically OCSP stapling (more specifically must-staple) is isomorphic to short-lived certificates.
alwillis 10mo ago
OSCP enables every website someone visits to be tracked; see https://news.ycombinator.com/item?id=46290033 https://news.ycombinator.com/item?id=46290033
- SkiFire13 10mo ago
  OSCP stapling (which OP mentions) is supposed to fix that though.

jfindper 10mo ago

While I believe you're posting questions out of frustration rather than genuine curiosity, I think it's worth pointing out two things. One: most of the reasoning is available for reading. Lots of discussion was had. If you're actually curious, I would suggest starting with the CA/B mailing group. Some conversation is in the MDSP (Mozilla's dev-security-policy) archives as well. Two: it's good to remember that the competing interests in almost every security-related conversation is the balance between security and usability. Obviously, a 60-second lifetime is unusable. The goal is to get the overlap between secure and usable to be as big as possible.

asah 10mo ago
serious q: maybe not 60 sec, but why 45 days instead of ~1 day or even hours? at 45 days, it pretty much has to be automated.
- ahoka 10mo ago
  They are not sadists, contrary to what others say in the comments.
  - jsheard 10mo ago
    Although for the benefit of masochists, they are going to offer 6 day certs as an option soon.
    - phasmantistes 10mo ago
      Yep, the "shortlived" (6-day) profile will be available to the general public later this week. But at this time we explicitly encourage only mature organizations with stable infrastructure and an oncall rotation to adopt that profile, as the risks associated with a renewal failing at the beginning of a holiday long weekend are just too high for many sites.
- tetha 10mo ago
  Our internal CAs run 72 hour TTLs, because we figured "why not" 5-6 years ago, and now everyone is too stubborn to stop. You'd be surprised how much software is bad at handling certificates well. It ranges from old systems like libpq which just loads certs on connection creation to my knowledge, so it works, down to some JS or Java libraries that just read certs into main memory on startup and never deal with them again. Or other software folding a feature request like "reload certs on SIGHUP" with "oh, transparently do listen socket transfer between listener threads on SIGHUP", and the latter is hard and thus both never happen. 45 days is going to be a huge pain for legacy systems. Less than 2 weeks is a huge pain even with modern frameworks. Even Spring didn't do it right until a year or two ago and we had to keep in-house hacks around.
- 10mo ago

benjiro 10mo ago

You know that the original idea was to drop it to 17 days?! And i think that is still on the books. To be honest, the issue is not the time frame, you can literally have certs being made every day. And there are plenty of ways to automated this. The issue is the CT log providers are going to go ape! Right now, we are at 24B certificates going back to around 2017 when they really started to grow. There are about 4.5B unique domains, if we reduce this to the amount of certs per domain, its about 2.3B domain certs we currently need. Now do 2.3B, x 8 renewals ... This is only about 18,4B new certs in CT logs per year. Given how popular LE is, we can assume that the actual growth is maybe 10B per year (those that still use 1 year or multi year + the tons of LE generated ones). Remember, i said the total going back to 2017 currently is now only 24B ... Yea, we are going to almost double the amount of certs in CT logs, every two years. And that assumes LE does not move to 17 days, because then i am sure we are doubling the current amount, each year. Good luck as a CT log provider... fyi, a typical certificate to store is about 4.5kb, we are talking 45TB of space needing per year, and 100TB+ if they really drop it down to 17 days. And we did not talk databases, traffic to the CT logs, etc... Its broken Jim ... Now imagine for fun, a daily cert, ... 1700TB per year in CT log storage? A new system will come from Google etc because its going to become unaffordable, even for those companies.

nickf 10mo ago
Where did you get 17 days from?
- benjiro 10mo ago
  There was talking going on in one of the CA/Browser Forum regarding certificate expirations, and how they looked at potentially 17 days. The 45 days was a compromise, but the whole 17 days was never removed from the table, and was still considered as a future option.
  - nickf 10mo ago
    Honestly don't recall discussing 17 days, but I could be wrong. 47 days was a 'compromise' in that it's a step-down over a few years rather than a single big-bang event dropping from 397->90/47/less.