Gânduri Eclectice – Eclectic Thoughts

If there is one thing guaranteed to annoy me, it is SECURITY THEATRE; things which are done in the name of security but have little if any actual value because of the naïve way in which they have been implemented. Sometimes this is because of lack or thought or actual naïveté. Sometimes it is through laziness coupled with wanting to be seen to be actually doing something. And sometimes the motivation is entirely more sinister.

I’m not entirely sure which this is, although I suspect the former or middle options.

What’s Up Doc?

“SC-081: Introduce Schedule of Reducing Validity and Data Reuse Periods” is what’s up. A proposal to the Certification Authority Browser Forum (CA/B Forum) from Apple, likely to be voted upon in the next few months.

It’s a proposal to further reduce, in a phased timetable, the lifetime of SSL/TLS certificates issued by Global CAs. The proposal is to reduce it from the current 13 months (398 days) (where is has been since 2020) to:

• 200 days after September 2025
• 100 days a year later in 2026
• 45 days after April 2027

My objection to this is the same as it was when I wrote about the reduction to 398 days in 2020: It’s security theatre, and the benefits are illusory!

Here’s the key part of what I wrote on 2020-09-01 on this subject:

The Illusion

And here is the problem: when renewing a certificate which is due to expire, many organisations still simply reuse their existing keypair by generating a new CSR (Certificate Signing Request) using the existing key material. Yet it is not the lifetime of the certificate which really matters – it is the amount of time for which the same private key is used. I’ve seen private keys in use for scarily long periods – ones so old that they were almost certainly compromised years ago by HeartBleed, for example.

The benefit of shorter certificate lifetimes cannot be realised unless new key material is used each time a new certificate is requested.

Reusing the same key material means there is NO security benefit to this, and lots of additional pain for sites where this type of process cannot reasonably be automated.

Remember, the keypairs underpinning TLS are just that: pairs of raw public & private keys. There are no “expiry” dates here – they are just raw keys. The only thing with a valid-from and valid-to date is the actual TLS certificate itself. And just to remind: the TLS certificate is comprised of 3 parts;

1. A public key
2. Identifying information:
   • The base name – the name used in the URL
   • The valid-from date/time
   • The valid-to date/time
3. A CA signature, asserting the binding together of (1) & (2) by the CA

This change has no security benefit at all. Reductio ad absurdum: I steal your TLS private key. You replace your TLS certificate with short lifetimes, say 45 days. You think that any exploitation is bracketed by this lifetime, but you are wrong: I can still decrypt all your traffic for as long as you use the same keypair because the security is predicated upon the private key being private and I’ve got your private key (which is no longer private) until you actually bother replacing it. Oh… and I can pretend to BE your website too, without end, until you replace that private key.

What SHOULD be done?

What should be done is not simple to implement and enforce, so no one is remotely likely to bother. What could be done could be done relatively easily is something which makes the effort of circumventing the control more effort than simply just doing the right thing.

Here’s what I would do as a Global CA:

• When a CSR (Certificate Signing Request) is received – a standard part of requesting a TLS certificate – check the public key it contains against previously issued certificates from this CA.
• If the public key has been used before, reject the CA with “new keypair required” as the error message.
• If it has not been used before, issue the cert (subject to all the existing checks & verification steps, that is!), and add the public key to the list of “used” public keys.

To circumvent this simplified control the requestor must use a different CA each time, and eventually will HAVE to replace their keypair.

Do this, and the certificate lifetime genuinely brackets the temporal blast radius of a private TLS key compromise.

Do this, and there would be benefits to further reducing the maximum permitted lifetimes – and a proper discussion could take place to identify the best balance between additional work and additional security.

Instead, we are left with yet more security theatre where organisations which do it properly in the first place (new cert always meaning new keypair) are likely no better off since they take security seriously anyway, and organisations which don’t replace their keypairs are no more secure but think that they are.

Enough with the security theatre. It’s pointless and wasteful.

Conclusions (or “What can organisations do themselves?”)

It’s fairly simple really. When you request a new TLS Certificate, always generate a new keypair first. Simples! This is all part of what I describe as “Good, and well managed, TLS”. The good part is about ciphersuites and TLS versions. The well-managed part includes this aspect, and others such as keeping your private key well-protected.

And if you get a chance to object to SC-081, then please do. In its current form, it is pointless.