7 ms·

I don't see the benefit of reducing the lifespan of these certificates. In a world where everyone could use let's encrypt it makes sense, but that's not realist

by gen3 7y ago

I don't see the benefit of reducing the lifespan of these certificates. In a world where everyone could use let's encrypt it makes sense, but that's not realistic for every company. I don't think it's worth the trouble.

OrgNet 7y ago
since they don't state the reason for this change, it is very suspicious and should not be granted
CydeWeys 7y ago
The linked article explains how longer certificate validity times cause issues when compromised certificates aren't revoked (as they often aren't). Limiting the lifespan of certificates reduces the potential fallout.
- danShumway 7y ago
  Completely honest, open question: I've seen advice coming out of companies like Microsoft that password expiration dates are not useful, in part because they encourage insecure practices, and in part because the scenario where someone gets access to your password and doesn't get around to hacking you for 3 months is just not that likely. Why doesn't that advice apply to certificates? A company that's setting up renewals might do so in a way that exposes their certificates to more of the workforce than necessary. Setting up automated renewal adds complication over the much simpler model of, "put this special file in a vault and on the production server, and then nobody in the company gets to touch it." It also doesn't seem likely that a compromised certificate wouldn't be exploited for an entire year. But the general advice I've seen from security professionals is that LetsEncrypt's renewal policy is helping, and forced password changes are hurting. So it seems like there's some dimension to this that I'm missing, either around how companies are typically implementing auto-renew, or how certificates get leaked and abused.
  - kace91 7y ago
    >I've seen advice coming out of companies like Microsoft that password expiration dates are not useful, in part because they encourage insecure practices, The need to come up with a new password and memorise constantly a new strong chain of characters is an unrealistic demand for regular users, that results in attempted get arounds (passwords with a correlative number, post it notes, etc). I don't think this kind of risk is present for certificate renovation, where it's safe to think that whoever is in charge of managing it has a security background.
    - danShumway 7y ago
      > where it's safe to think that whoever is in charge of managing it has a security background. Or even if they don't have a security background, that they'd at least be more secure than the average user. I guess a certificate is also something that you don't need to write down and remember, which could help. Would a good takeaway be that expiring passwords would be helpful, if users weren't terrible about password management?
      - kace91 7y ago
        >Would a good takeaway be that expiring passwords would be helpful, if users weren't terrible about password management? Absolutely, which is why it was considered a good practice in the past. A case of not taking into account the human factor /usability aspect.
        tdewitt 7y ago
        It was a "good enough" practice until better options came along. It's never been a "good" practice. Take a look at lists of breached passwords and you'll see an overwhelming number of passwords that involve replacing vowels with numbers in common words. Humans are bad at picking complex passwords because they're not easy to remember. We had to adjust the rules over time to deal with that: minimum complexity rules, require a capital letter, require a number, require a "special" (but not too special because we still don't do proper sanitization), no repeating the same password until you've rotated N times, no repeating the same password until you've rotated N times AND there's a minimum age. Those rules all camebinto play because people can't be relied on to be smart about passwords. Password expirations are insufficient and it has always been a game of cat-and-mouse with people who hate them. Good security is something people willingly use or don't know they're using, so they don't try and work around it.
jazzyjackson 7y ago
I'm ignorant, Why can't everyone use Let's Encrypt?
- ben509 7y ago
  Read their docs[1] especially Getting Started[2]. It's not bad, but you still need some experience administering a server and understanding of security and networking to do it. Other automated systems like ACM[3] are very easy, but assume you've bought into a more expensive infrastructure, and often only support their (AWS's in this case) services. And at the other extreme, there are a plethora of simple web hosting packages[4] that only serve very cookie cutter setups. That leaves a decent number of smaller organizations or individuals that aren't really able to take advantage of automation because it doesn't support their configuration, or because they don't have the expertise to set it up correctly. So they are often stuck renewing manually. [1]: https://letsencrypt.org/docs/ https://letsencrypt.org/docs/ [2]: https://letsencrypt.org/getting-started/ https://letsencrypt.org/getting-started/ [3]: https://aws.amazon.com/certificate-manager/ https://aws.amazon.com/certificate-manager/ [4]: https://www.gandi.net/en/simple-hosting https://www.gandi.net/en/simple-hosting
- thekyle 7y ago
  Politically speaking, it's probably not the best idea to have one organization issuing all SSL certs used on the web.
  - ferzul 7y ago
    but that's solved, not by avoiding the automated, short term, machine aided certificate generation by Acme Bot and related tools, but by spreading them to other CAs. And every time someone says, can't everyone just use LetsEncrypt, they mean, why haven't they automated it?
    - throw0101a 7y ago
      ACME only became an RFC in March 2019: it's a Johnny Come Lately to the cert world. And it's not like it was the first/only game in town for cert issuing APIs: * https://en.wikipedia.org/wiki/Enrollment_over_Secure_Transport https://en.wikipedia.org/wiki/Enrollment_over_Secure_Transpo... * https://en.wikipedia.org/wiki/Simple_Certificate_Enrollment_Protocol https://en.wikipedia.org/wiki/Simple_Certificate_Enrollment_... ACME is the third kick at the can AFAICT. Some people could perhaps be excused for thinking ACME/LE was just another flash in the pan.
quotemstr 7y ago
Out of curiosity: why isn't it realistic for every company?
- 693471 7y ago
  It is, some people just think making them hire better engineers and fix shitty infra is too hard
- t0mas88 7y ago
  Some systems aren't internet connected 24/7 and thus not able to autorenew all the time. Not a problem if someone has to do it manually every year or two years, but it becomes a bigger issue if you need to renew a cert every 30 days.
  - throw0101a 7y ago
    Also, some systems are internal only, so can't use http-01 validation. We have a bunch of these like this, so for our "foo.int.example.com" systems, in our public DNS we have a CNAME pointing to "foo.int.dnsauth.example.com", and have set up a new DNS infrastructure so that we can use dns-01 validation of TXT records there: * https://github.com/Neilpang/acme.sh/wiki/DNS-alias-mode https://github.com/Neilpang/acme.sh/wiki/DNS-alias-mode * https://dan.langille.org/2019/02/01/acme-domain-alias-mode/ https://dan.langille.org/2019/02/01/acme-domain-alias-mode/ * https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se... I had no idea that this functionality existed until fairly recently.
    - AstralStorm 7y ago
      And the DNSSEC is authenticated with how often renewed certificate? If there's no DNSSEC, this is entirely worthless. DNS is very easy to attack.
      - tptacek 7y ago
        CAs are in general CT-logged now, and major sites all monitor the CT logs (hell, even small sites do at this point). If it's so easy to attack DNS to achieve misissuance, why isn't it happening all the time?
MertsA 7y ago
If your infrastructure is complicated enough to make let's encrypt non viable then you're large enough that a certificate renewal period of a year isn't that onerous to begin with. If anything at that point having multi-year long renewal periods just leads to more of a headache when it inevitably gets forgotten about since it's such an infrequent task.

by gen3 7y ago

OrgNet 7y ago

since they don't state the reason for this change, it is very suspicious and should not be granted

CydeWeys 7y ago

The linked article explains how longer certificate validity times cause issues when compromised certificates aren't revoked (as they often aren't). Limiting the lifespan of certificates reduces the potential fallout.

danShumway 7y ago
Completely honest, open question: I've seen advice coming out of companies like Microsoft that password expiration dates are not useful, in part because they encourage insecure practices, and in part because the scenario where someone gets access to your password and doesn't get around to hacking you for 3 months is just not that likely. Why doesn't that advice apply to certificates? A company that's setting up renewals might do so in a way that exposes their certificates to more of the workforce than necessary. Setting up automated renewal adds complication over the much simpler model of, "put this special file in a vault and on the production server, and then nobody in the company gets to touch it." It also doesn't seem likely that a compromised certificate wouldn't be exploited for an entire year. But the general advice I've seen from security professionals is that LetsEncrypt's renewal policy is helping, and forced password changes are hurting. So it seems like there's some dimension to this that I'm missing, either around how companies are typically implementing auto-renew, or how certificates get leaked and abused.
- kace91 7y ago
  >I've seen advice coming out of companies like Microsoft that password expiration dates are not useful, in part because they encourage insecure practices, The need to come up with a new password and memorise constantly a new strong chain of characters is an unrealistic demand for regular users, that results in attempted get arounds (passwords with a correlative number, post it notes, etc). I don't think this kind of risk is present for certificate renovation, where it's safe to think that whoever is in charge of managing it has a security background.
  - danShumway 7y ago
    > where it's safe to think that whoever is in charge of managing it has a security background. Or even if they don't have a security background, that they'd at least be more secure than the average user. I guess a certificate is also something that you don't need to write down and remember, which could help. Would a good takeaway be that expiring passwords would be helpful, if users weren't terrible about password management?
    - kace91 7y ago
      >Would a good takeaway be that expiring passwords would be helpful, if users weren't terrible about password management? Absolutely, which is why it was considered a good practice in the past. A case of not taking into account the human factor /usability aspect.
      - tdewitt 7y ago
        It was a "good enough" practice until better options came along. It's never been a "good" practice. Take a look at lists of breached passwords and you'll see an overwhelming number of passwords that involve replacing vowels with numbers in common words. Humans are bad at picking complex passwords because they're not easy to remember. We had to adjust the rules over time to deal with that: minimum complexity rules, require a capital letter, require a number, require a "special" (but not too special because we still don't do proper sanitization), no repeating the same password until you've rotated N times, no repeating the same password until you've rotated N times AND there's a minimum age. Those rules all camebinto play because people can't be relied on to be smart about passwords. Password expirations are insufficient and it has always been a game of cat-and-mouse with people who hate them. Good security is something people willingly use or don't know they're using, so they don't try and work around it.

jazzyjackson 7y ago

I'm ignorant, Why can't everyone use Let's Encrypt?

ben509 7y ago
Read their docs[1] especially Getting Started[2]. It's not bad, but you still need some experience administering a server and understanding of security and networking to do it. Other automated systems like ACM[3] are very easy, but assume you've bought into a more expensive infrastructure, and often only support their (AWS's in this case) services. And at the other extreme, there are a plethora of simple web hosting packages[4] that only serve very cookie cutter setups. That leaves a decent number of smaller organizations or individuals that aren't really able to take advantage of automation because it doesn't support their configuration, or because they don't have the expertise to set it up correctly. So they are often stuck renewing manually. [1]: https://letsencrypt.org/docs/ https://letsencrypt.org/docs/ [2]: https://letsencrypt.org/getting-started/ https://letsencrypt.org/getting-started/ [3]: https://aws.amazon.com/certificate-manager/ https://aws.amazon.com/certificate-manager/ [4]: https://www.gandi.net/en/simple-hosting https://www.gandi.net/en/simple-hosting
thekyle 7y ago
Politically speaking, it's probably not the best idea to have one organization issuing all SSL certs used on the web.
- ferzul 7y ago
  but that's solved, not by avoiding the automated, short term, machine aided certificate generation by Acme Bot and related tools, but by spreading them to other CAs. And every time someone says, can't everyone just use LetsEncrypt, they mean, why haven't they automated it?
  - throw0101a 7y ago
    ACME only became an RFC in March 2019: it's a Johnny Come Lately to the cert world. And it's not like it was the first/only game in town for cert issuing APIs: * https://en.wikipedia.org/wiki/Enrollment_over_Secure_Transport https://en.wikipedia.org/wiki/Enrollment_over_Secure_Transpo... * https://en.wikipedia.org/wiki/Simple_Certificate_Enrollment_Protocol https://en.wikipedia.org/wiki/Simple_Certificate_Enrollment_... ACME is the third kick at the can AFAICT. Some people could perhaps be excused for thinking ACME/LE was just another flash in the pan.

quotemstr 7y ago

Out of curiosity: why isn't it realistic for every company?

693471 7y ago
It is, some people just think making them hire better engineers and fix shitty infra is too hard
t0mas88 7y ago
Some systems aren't internet connected 24/7 and thus not able to autorenew all the time. Not a problem if someone has to do it manually every year or two years, but it becomes a bigger issue if you need to renew a cert every 30 days.
- throw0101a 7y ago
  Also, some systems are internal only, so can't use http-01 validation. We have a bunch of these like this, so for our "foo.int.example.com" systems, in our public DNS we have a CNAME pointing to "foo.int.dnsauth.example.com", and have set up a new DNS infrastructure so that we can use dns-01 validation of TXT records there: * https://github.com/Neilpang/acme.sh/wiki/DNS-alias-mode https://github.com/Neilpang/acme.sh/wiki/DNS-alias-mode * https://dan.langille.org/2019/02/01/acme-domain-alias-mode/ https://dan.langille.org/2019/02/01/acme-domain-alias-mode/ * https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se... I had no idea that this functionality existed until fairly recently.
  - AstralStorm 7y ago
    And the DNSSEC is authenticated with how often renewed certificate? If there's no DNSSEC, this is entirely worthless. DNS is very easy to attack.
    - tptacek 7y ago
      CAs are in general CT-logged now, and major sites all monitor the CT logs (hell, even small sites do at this point). If it's so easy to attack DNS to achieve misissuance, why isn't it happening all the time?

MertsA 7y ago

If your infrastructure is complicated enough to make let's encrypt non viable then you're large enough that a certificate renewal period of a year isn't that onerous to begin with. If anything at that point having multi-year long renewal periods just leads to more of a headache when it inevitably gets forgotten about since it's such an infrequent task.