4 ms·

Am I the only one a bit annoyed by the 90 day expiry limit? Although the reasoning for automation is sound, I don't see how a small expiry limit actually improv

Am I the only one a bit annoyed by the 90 day expiry limit? Although the reasoning for automation is sound, I don't see how a small expiry limit actually improves security [as stated in one of the reasons] in any way. Especially given the cert is basically now a requirement to get onboard with http2 at all. I truly appreciate the heroic efforts of let's encrypt, however that seems to be an annoying middle step before DNSSEC.

simoncion 11y ago
> however that seems to be an annoying middle step before DNSSEC. Do tell. How is LE a middle step before DNSSEC? (I would appreciate it if only tenfingers replies. I'm interested in his response, not speculation from the rest of us. :) )
mei0Iesh 11y ago
Maybe I could see annoyance about the perceived dependency on Let's Encrypt. If someone is used to setting it for multiple years, then feeling like the transaction is complete for a long while, then LE could appear too involved. It's almost like the server needs a permanent attachment to an organization, to keep pinging to ask permission to exist on the web. If everyone goes 100% HTTPS/2, with automated renewal, then one could imagine a possible scenario where Let's Encrypt going out of service would break large chunks of the web. Or gives them too much power to selectively deny renewal and break sites with unattentive admins. I'd be a little hesitant to switch commercial or critical sites to using Let's Encrypt right now. But overall, no, I like automated renewal. I think I'd choose to get a new certificate monthly, instead of 3 months. The provider I was using before with very low prices requires me to go through a manual process through their website. The main feature to me that'll cause me to switch is being able to set it and forget it. With automated monthly renewals, the 90 day expiry is extra buffer in case something goes wrong.
tenfingers 11y ago
I'm tired of downvotes without explaination. You don't see a problem with a new automation that when breaks basically brings down your website? Or any problem with letsencrypt basically giving you only <90 days to generate a cert with somebody else? I also really want to have the argument for improved security. Because a compromised host can now generate new certs for himself at zero cost as well, so what's the real point behind the 90 day limit? Giving NSA less time to crack your key? Thanks for clarifying.
- simoncion 11y ago
  > You don't see a problem with a new automation that when breaks basically brings down your website? A TLS cert change doesn't bring down your website. Swap the old cert for the new and reload. Done. > Or any problem with letsencrypt basically giving you only <90 days to generate a cert with somebody else? Look at the folks behind the project. Take a good look at the folks running and funding the project. They know how to run an essential Internet service. Moreover, they will give you more than 90 days notice if they ever need to shut Let's Encrypt down. Frankly, you can level this criticism at any vendor that's a potential SPoF. It's not a good complaint when it's so general. > Because a compromised host can now generate new certs for himself at zero cost as well... Because -AIUI- CRLs don't currently work well -in practice-, a 90 day window of cert validity limits the amount of time a given cert can be out in the wild, impersonating your site. > ...what's the real point behind the 90 day limit? Giving NSA less time to crack your key? If I might snark for a second: 1) If your box is pwnd, and your private keys aren't in an HSM, then there's no need to try crack your key. 2) AFAIK, there is no non-brute force attack against the public part of a correctly generated TLS keypair that will reveal the private part of the key. (Or am I totally wrong about how TLS works, and there's only a private key? I can't remember. :( )
  - dingaling 11y ago
    > a 90 day window of cert validity limits the amount of time a given cert can be out in the wild, impersonating your site. But a the OP pointed-out, if a site using LE is compromised then the attacker has basically an infinite duration of valid certs, because they are automatically renewed. There is no manual challenge to receive a new cert. So essentially the validity period of an LE cert means nothing.
    - zeendo 11y ago
      ...that's only true while the attacker controls the site. The 90 day window mitigates the effect of the cert being leaked. Just because I grabbed a site's cert on day doesn't mean I control the site. In fact, there's nothing to say I even compromised the site to get the cert in the first place. Perhaps it was mishandled internally? Or grabbed via a heartbleed-style attack?
DasIch 11y ago
There is no way to reliably revoke certificates. Therefore it's crucial to keep a short expiry limit. 90 days isn't short, it's about 89 days too long.
eloy 11y ago
> Especially given the cert is basically now a requirement to get onboard with http2 at all. That was a proposal before the specs of HTTP/2 were official, it's not a requirement anymore. > I truly appreciate the heroic efforts of let's encrypt, however that seems to be an annoying middle step before DNSSEC. I don't think that DNSSEC is a great idea. Chrome supported DANE for a while, but they removed the support for it. TLS + HPKP + HSTS is working great, DNSSEC don't improve a lot when we would add it.
- X-Istence 11y ago
  It's not a requirement per spec, however it is a requirement for all major browsers.
hannob 11y ago
The security argument makes sense. The background is the following: Right now certificate revocation is essentially broken. There are two mechanisms (CRL and OCSP), and both don't work. CRL for obvious scalability issues and OCSP because you'd need near 100% uptime of the OCSP responder for it to be reasonable and never have any firewall (think of captive portals) that blocks the conncetion to OCSP. Therefore browsers decided either to implement OCSP insecurely with a soft fail (mostly pointless) or not at all. So we have no working revocation. Someone hacks into your server and steals your key and uses it to attack your users. What do you do? Of course you revoke your cert, but it doesn't really make a difference. People have been thinking how to fix revocation. One way would be OCSP Stapling + must staple. But that's still a long way till this will work (the ocsp stapling implementations of both apache and nginx would need a huge overhaul, they are pretty bad and not up to the task). Short lived certificates are a way to make revocation less important, because it reduces the time a hacked key can be used. And if this really bothers you a lot: There are two other free CAs that will give you one year certs: StartSSL and Wosign.
- deleted 11y ago
  [deleted]
- deleted 11y ago
  [deleted]

simoncion 11y ago

> however that seems to be an annoying middle step before DNSSEC. Do tell. How is LE a middle step before DNSSEC? (I would appreciate it if only tenfingers replies. I'm interested in his response, not speculation from the rest of us. :) )

mei0Iesh 11y ago

Maybe I could see annoyance about the perceived dependency on Let's Encrypt. If someone is used to setting it for multiple years, then feeling like the transaction is complete for a long while, then LE could appear too involved. It's almost like the server needs a permanent attachment to an organization, to keep pinging to ask permission to exist on the web. If everyone goes 100% HTTPS/2, with automated renewal, then one could imagine a possible scenario where Let's Encrypt going out of service would break large chunks of the web. Or gives them too much power to selectively deny renewal and break sites with unattentive admins. I'd be a little hesitant to switch commercial or critical sites to using Let's Encrypt right now. But overall, no, I like automated renewal. I think I'd choose to get a new certificate monthly, instead of 3 months. The provider I was using before with very low prices requires me to go through a manual process through their website. The main feature to me that'll cause me to switch is being able to set it and forget it. With automated monthly renewals, the 90 day expiry is extra buffer in case something goes wrong.

tenfingers 11y ago

I'm tired of downvotes without explaination. You don't see a problem with a new automation that when breaks basically brings down your website? Or any problem with letsencrypt basically giving you only <90 days to generate a cert with somebody else? I also really want to have the argument for improved security. Because a compromised host can now generate new certs for himself at zero cost as well, so what's the real point behind the 90 day limit? Giving NSA less time to crack your key? Thanks for clarifying.

simoncion 11y ago
> You don't see a problem with a new automation that when breaks basically brings down your website? A TLS cert change doesn't bring down your website. Swap the old cert for the new and reload. Done. > Or any problem with letsencrypt basically giving you only <90 days to generate a cert with somebody else? Look at the folks behind the project. Take a good look at the folks running and funding the project. They know how to run an essential Internet service. Moreover, they will give you more than 90 days notice if they ever need to shut Let's Encrypt down. Frankly, you can level this criticism at any vendor that's a potential SPoF. It's not a good complaint when it's so general. > Because a compromised host can now generate new certs for himself at zero cost as well... Because -AIUI- CRLs don't currently work well -in practice-, a 90 day window of cert validity limits the amount of time a given cert can be out in the wild, impersonating your site. > ...what's the real point behind the 90 day limit? Giving NSA less time to crack your key? If I might snark for a second: 1) If your box is pwnd, and your private keys aren't in an HSM, then there's no need to try crack your key. 2) AFAIK, there is no non-brute force attack against the public part of a correctly generated TLS keypair that will reveal the private part of the key. (Or am I totally wrong about how TLS works, and there's only a private key? I can't remember. :( )
- dingaling 11y ago
  > a 90 day window of cert validity limits the amount of time a given cert can be out in the wild, impersonating your site. But a the OP pointed-out, if a site using LE is compromised then the attacker has basically an infinite duration of valid certs, because they are automatically renewed. There is no manual challenge to receive a new cert. So essentially the validity period of an LE cert means nothing.
  - zeendo 11y ago
    ...that's only true while the attacker controls the site. The 90 day window mitigates the effect of the cert being leaked. Just because I grabbed a site's cert on day doesn't mean I control the site. In fact, there's nothing to say I even compromised the site to get the cert in the first place. Perhaps it was mishandled internally? Or grabbed via a heartbleed-style attack?

DasIch 11y ago

There is no way to reliably revoke certificates. Therefore it's crucial to keep a short expiry limit. 90 days isn't short, it's about 89 days too long.

eloy 11y ago

> Especially given the cert is basically now a requirement to get onboard with http2 at all. That was a proposal before the specs of HTTP/2 were official, it's not a requirement anymore. > I truly appreciate the heroic efforts of let's encrypt, however that seems to be an annoying middle step before DNSSEC. I don't think that DNSSEC is a great idea. Chrome supported DANE for a while, but they removed the support for it. TLS + HPKP + HSTS is working great, DNSSEC don't improve a lot when we would add it.

X-Istence 11y ago
It's not a requirement per spec, however it is a requirement for all major browsers.

hannob 11y ago

The security argument makes sense. The background is the following: Right now certificate revocation is essentially broken. There are two mechanisms (CRL and OCSP), and both don't work. CRL for obvious scalability issues and OCSP because you'd need near 100% uptime of the OCSP responder for it to be reasonable and never have any firewall (think of captive portals) that blocks the conncetion to OCSP. Therefore browsers decided either to implement OCSP insecurely with a soft fail (mostly pointless) or not at all. So we have no working revocation. Someone hacks into your server and steals your key and uses it to attack your users. What do you do? Of course you revoke your cert, but it doesn't really make a difference. People have been thinking how to fix revocation. One way would be OCSP Stapling + must staple. But that's still a long way till this will work (the ocsp stapling implementations of both apache and nginx would need a huge overhaul, they are pretty bad and not up to the task). Short lived certificates are a way to make revocation less important, because it reduces the time a hacked key can be used. And if this really bothers you a lot: There are two other free CAs that will give you one year certs: StartSSL and Wosign.

deleted 11y ago
[deleted]
deleted 11y ago
[deleted]