Pros and cons of 90-day certificate lifetimes

[eva2000]

@jsha

As @germeier said, several months so we can get more data on how issuance and renewal in practice.

hopefully the rate limits are gone for several of those months so you can see how full operation load looks too

[serverco]

From my perspective, please keep it at 90 days, or shorter. There is still a little work to be done on automation scripts for everything, it’ll get there though

[rugk]

@NOYB

I find it quite telling that neither you nor anyone else identified as a LE representative or spokesperson has addressed it directly.

Just remember that they do not always have time to reply to every community discussion coming up here...
E.g.

@jsha

Apologies for the absence, we've had a busy week.

And I think there are more important points currently than replying to every small discussion here. The short statement: "Everything was already said there" is already a reply of some kind.
I mean you have not addressed the replies there too.

[rugk]

@acetylator

I have written a simple bash script which renews all certificates every 60 days. If renewal fails, I get an email, so I have at least 30 days to fix the issue.

FYI that's exactly like the behaviour of the official LE clients too.
So if I understood this correctly you created another ACME client in Bash. And as diversity is nice and some other users may also like it: Is it open-sourced and published somewhere? (GitHub/GitLab/...)

[rugk]

@acetylator

I think that we are getting completely off-topic here.

A small tip: "Reply as linked Topic"
(if your [off-topic-]reply to my previous post here should get too long I would also recommend to make use of this in this case)

[acetylator]

It’s not on GitHub, it’s directly here. It’s a very simple one, nothing to brag about, but it’s something that suits me very well. The title says that it’s for Debian Jessie, but it should work on any Debian. I have not tested it on other distros. Enjoy or modify it for your needs
How-to: completely automating certificate renewals on Debian

[yngndrw]

@NOYB I’d like to sell you a tin-foil hat.

Jokes aside, if a government agency wanted to snoop on traffic they could just strong-arm any CA into producing a new certificate for them to use that covers your domain. They then just have to host Cloudflare-style proxy to decrypt, monitor and re-encrypt any traffic protected by the TLS. Ultimately the vulnerability here is the chain of trust, but this is totally unrelated to the duration of the certificates.

I think @linuxtech’s response to your thread regarding the shorter duration being more secure against key cracking attempts also serves as a nice reason for ensuring the shorter maximum certificate duration. The revocation benefits mentioned above in this thread would also be the other key reason for the shorter durations in my opinion.

[NOYB]

@yngndrw

if a government agency wanted to snoop on traffic they could just strong-arm any CA into producing a new certificate for them to use that covers your domain. They then just have to host Cloudflare-style proxy to decrypt, monitor and re-encrypt any traffic protected by the TLS.

Too detectable. Not covert enough.
Only works for live session (MITM). Not post capture analysis (of non-MITM).

Gov surveillance entities what to get away from needing to use MITM techniques.

[yngndrw]

Then what sorts of back doors are you referring to in your post ? I believe that only the use of weak algorithms would be a viable attack and that attack is mitigated by the use of certificate signing requests - I.e. The private key is generated by your client and never sent to the server, as mentioned by @Leliana.

It should be noted that even with perfect forward secrecy, any captured sessions are still at risk of being exposed if the underlying cipher is broken. This feeds back into the earlier point of shorter certificate durations being more secure in this regard, as breaking the cipher for one session exposes a smaller amount of data, requiring more computing effort to expose data over a period longer than 90 days.

[NOYB]

You’re making an assumption regarding their lack of ability to build in backdoors. I’m saying their ability far exceed that which is commonly known.

[yngndrw]

Well to be fair, you also seem to be making assumptions about their abilities unless you can provide some evidence or even just specific examples of their capabilities. Without any specifics, it’s hard to discuss the point you’ve raised.

Of course if we assume that their capabilities are really that advanced, it would seem that SSL would do little to prevent their snooping if they really wanted to do so. I’m not certain what benefit they’d have from having access to the public portion of the certificate signing process alone aside from the afore-mentioned MITM attacks ?

[jsha]

Reminder: Discussions of how to go about backdooring a CA are offtopic for this thread, which is about concrete pros and cons of 90-day certificate lifetimes. @NOYB helpfully started a thread at Surveillance Advantages of Short Lifetime Certificates if you’d like to follow up there.

Also as a reminder: If you are posting to express your support for longer lifetimes, without discussing a specific pro or con, please “like” the first post in this thread. This helps keep the signal-to-noise ratio high.

[piano]

BTW Congratulations on reaching public beta!

@jsha

There's no way as an end user to tell whether an unrecognized certificate is legitimate or not.

Not true. There are a few (admittedly rare) cases where a user can trust a cert without having to rely on the CA trust model.

eg: if a cert has been observed in use for a while, or (re)uses a subject public key that has been, the end user can be fairly confident the cert is legit, particularly because of things like:

@jsha

Site operators ... can subscribe to monitors and be alerted

But if switching both certs and keys really often becomes common, those few cases in which users can effectively practice this kind of self-defense become even rarer.

And, of course, it's no real comfort to:

@jsha

(eventually) be alerted

...if you've got to decide today whether to trust a site with your password or not, and live with the results (users are the ones most affected by MITMs, not site operators or CAs).

I just read that the LE renewal script will default to generating a new key rather than re-using the current one:

@jcjones

I'm told right now the idea is regenerate by default

I really hope that's not true. If it is, I hope it's due to some practical barrier or other that I can help remove?

Obviously there is a trade-off and we wouldn't want keys being re-used for 10 or 20 years either! I would suggest LE defaults to re-using the same key for 1 or 2 years.

[yngndrw]

I’ve always been against pinning as it causes problems when you want to quickly change algorithm after a vulnerability has been detected and ultimately offers little benefit if you trust the trust model. We fell foul of this at work where we needed to change from sha1 certificates, but other teams using our service were pinning on our old certificate - These teams had native desktop applications which has no forced update method even within a longer period such as 6 months.

Additionally not rotating the keys frequently negates one of the main security benefits of using short durations so for these reasons I would be against the proposition of retaining the keys, especially as a default option.

[My1]

well I would say that TLSA Pininng works a lot better because they dont rely on long-term-storage of the browser.

also since keys are used for the pinning a sole change f the algo wont hurt pinning, also you should always have some backup keys.

[jsha]

I’ve forked off the pinning conversation over here: Pinning and SHA1 migration.

[piano]

@yngndrw

I've always been against pinning as it causes problems when you want to quickly change algorithm after a vulnerability has been detected and ultimately offers little benefit if you trust the trust model.

That's a very big if. Why would you trust the CA trust model?

It's thoroughly broken for the purposes of defending against nation-states, and partly broken even for defending against smaller attackers.

Edit: Sorry for starting a tangent, I posted this before I saw jsha had forked the conversation and can't see an option to delete post, only edit.

[rugk]

@piano

I'm told right now the idea is regenerate by default

I really hope that's not true. If it is, I hope it's due to some practical barrier or other that I can help remove?

I think you missed the "by default".
You can always let the client ask to only renew the cert and not to regenerate it every time.

[nka]

I was going to generate one for my Firewall… until I notice the 90 days

[lyda]

I like certs being used for 90 days, but I’d renew them 30 days before they expire. An expiry time of 120 days seems more reasonable.

The automated renewal would be very good. Particularly if a multi-step process was set up for the manual version to allow people to script things for their internal systems.