Google wants to reduce lifespan for HTTPS certificates to one year | Hacker News Reader

Google wants to reduce lifespan for HTTPS certificates to one year

zdnet.com

61 pointswalterbell42 comments

Reduce them to 1 week, or even 1 day.

That will force operations to run tip-top. It will force much TLS software to learn to reload certificates automatically.

Most critically, it will mean not needing CRLs or OCSP.

why not after every request then?

Then you’ve kinda reinvented Kerberos or at least half of it. You’d be creating a hell of a lot of load on the server and the CA generating and signing all those new certificates.

Way back when “Grid computing” was a thing you’d use daily client certificates. You’d be issued a highly restricted signing cert which could only be used to generate extremely short lived certificates with your user CN. Which avoids the whole melting CA issue by having the end user generate them.

Kerberos tickets are cacheable and cached, and the load on KDCs is not high. But Kerberos does require always-online infrastructure, whereas PKIX requires revocation, which requires... always-online infrastructure. The only reason Kerberos doesn't have revocation protocols is that its tickets are short-lived, and that's how to avoid the need for revocation with PKIX: use fresh, short-lived certificates.

Technically, you could deliver revocations via a carrier pigeon, but of course it opens a joke hole of an attack. Unless it's a short distance for the pigeons.

As does automatic unvetted certificate signing (because non-repudiation), or automatic instant revocation process. (Denial of service or downgrade)

Pick your poison.

People get bit by certificate expiration all the time.

The only way to make sure you don't get bitten by things like certificate expiration is to exercise update path often, and the more often the better.

Because the rate of renewal needed to not need CRLs or OCSP is not that high.

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.

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.

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.

>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.

> 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?

>Would a good takeaway be that expiring passwords would be helpful, if users weren't terrible about password management?

I think that's a fair assessment. Passwords are doubly risky in that they're regularly touched by human hands, and often transmitted directly over the network.

I think about security more often than many people I work with, but I recognize that I'm not immune to phishing myself. Rotating passwords sounds like a great idea, but in practice it results in people just choosing terrible passwords. Better to encourage systems that reduce the possibility for human error in the first place IMO (think WebAuthn and friends).

> I guess a certificate is also something that you don't need to write down and remember, which could help.

That's the main difference IMHO.

Certs that need some manual procedure to renew already share one of the problems of changing passwords: it's yet another notification that something needs to be done soon(tm), and sometimes it will not happen until it's too late.

First, users aren't terrible about password management. Passwords are a terrible system. If most people can't use the system correctly, it means that the system is a failure.

That failed system just happens to be the one we have been stuck with, because the solutions are to give users hardware (to prove possession) and/or build hardware into devices (to verify biometrics).

Generally not. The biggest risk with passwords is not that an attacker will magically pull them from the ether, but that they are revealed as part of a security breach.

The best password is not one thats overly complex or that you require the user to change on a set schedule. It's one that is unique.

Of course, once you have a second factor, you can resort back to much simpler, shared passwords and still retain security.

>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.

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.

Speaking specifically in terms of compromise, and not in protection against compromise:

Certificates are part of a decentralized, delegated trust system. They are effectively a cache of a security decision.

With passwords, the security decision is made each time you log in.

If the statement in a certificate is no longer true, you need a mechanism like OCSP stapling (I suppose - because everything else, OCSP and CRLs, have failed).

If your password is compromised, it just needs to be changed in the database or directory. The password won't be usable anymore.

Now, kerberos tickets based on the compromised password may still be good for a few more hours, but thats another story.

This is a really good point that I was missing. I kind of assumed that when people talked about the difficulty of de-issuing certificates, they just mean that companies would be slow to do it.

The fact that there is no central point of authority by default that can say "no, it's not good anymore" -- that changes a lot of things, because now your expiration date is effectively the only good way to get rid of the certificate.

That puts LetsEncrypt's 3 month model in a different light -- it's not just aggressive to force people to automate the renewal process, 3 months is literally just way better than a year for security purposes.

The reasons to not expire passwords are that people will come up with dumb ones, write them down in plain sight, and/or forget them outright. None of these apply to certificate revocation. Passwords have very little in common with certificates, right down to the encryption algorithms. Certificates use public key encryption whereas passwords use secure hashes.

What's wrong with forgetting passwords? After a period of trying to use diffent passwords on different sites, I recently gave up and just type in some gibberish pattern I can reproduce three times (maybe via the clipboard), and then use password reset next time I need to log in.

Is this desperately insecure?

It doesn't work for everything I guess - online banking, email, work MS password. But if it's only three nonshared passwords it's tolerable.

Forgotten passwords require the use of password reset flows, and password reset flows are a notorious security weak point, whether it's because the security question answers can be gotten from publicly available information or guessed, or the email or SMS used for the reset flow is compromised, or the codes used are too short and can be brute-forced, or a variety of other issues.

The safest password is one that is never forgotten, and that has a truly onerous password reset flow, e.g. needing to go in person with ID to get it reset, potentially with someone else to vouch for you (how it works at many companies). Password reset flows are ways to get around the password mechanism itself, and the more often people forget their passwords, the smoother that flow (i.e. password bypass) needs to be.

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.

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

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.

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://dan.langille.org/2019/02/01/acme-domain-alias-mode/

* https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...

I had no idea that this functionality existed until fairly recently.

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.

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?

It is, some people just think making them hire better engineers and fix shitty infra is too hard

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

What about an internal machine, with no outside [incoming] connectivity? But you don't want to install your own self signed certificate on everyone's browsers.

There's no way for letsencrypt to issue you a certificate because they can't connect to it from outside.

If you are using DNS challenge type, then LetsEncrypt doesn't have to talk to the internal service. You just need the name of the internal service to be in public DNS. (You don't even need its internal IP address in there, LetsEncrypt only looks at the TXT record of _acme-challenge.)

Thought of that, but you need DNS software that allows scripted updates. You also need company policies that allow this.

We gave up and paid for a certificate.

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/ [2]: https://letsencrypt.org/getting-started/ [3]: https://aws.amazon.com/certificate-manager/ [4]: https://www.gandi.net/en/simple-hosting

Politically speaking, it's probably not the best idea to have one organization issuing all SSL certs used on the web.

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?

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_Transpo...

* 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.

There may be systems that do not allow for it. For example, $WORK's Barracuda mail filtering system doesn't have a useful way to do it via the command line, and if you want to enter a new cert you have to copy-and-paste via the GUI.

Up until recently, F5's BIG-IP LTM didn't have an automated way to do it either, but since it's an appliance that is basically running on top of CentOS, you can SSH in and get a bash shell and run something like dehydrated (minimal dependencies):

* https://lnxgeek.org/doku.php/indexes:let_s_encrypt_-_how_to_...

There's stuff out there besides just Apache and Nginx on a Linux system, and it can't all be automated.

They don't necessarily have to - the protocol Lets Encrypt uses (ACMEv2) is an IETF standard, and other CAs support it.

Because they don't issue EV.

Browser vendors are paying less and less attention to EV anyway [0].

[0]: https://www.troyhunt.com/extended-validation-certificates-ar...

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

Reply on news.ycombinator.com