Remix clone Hacker News

Can you point to a specific security problem this change is actually solving? For example, can we attribute any major security compromises in the last 5 years to TLS certificate lifetime?

Are the security benefits really worth making anything with a valid TLS certificate stop working if it is air-gapped or offline for 48 days?

> CAs and certificate consumers (browsers) voted in favour of this change. They didn't do this because they're incompetent but because they think it'll improve security.

They're not incompetent and they're not "evil", and this change does improve some things. But the companies behind the top level CA ecosystem have their own interests which might not always align with those of end users.

▲

dextercd 4 days ago | parent | next [-]

If a CA or subscriber improves their security but had an undetected incident in the past, a hacker today has a 397 day cert and can reuse the domain control validation in the next 397 days, meaning they can MITM traffic for effectively 794 days.

CAs have now implemented MPIC. This may have thwarted some attacks, but those attackers still have valid certificates today and can request a new certificate without any domain control validation being performed in over a year.

BGP hijackings have been uncovered in the last 5 years and MPIC does make this more difficult. https://en.wikipedia.org/wiki/BGP_hijacking

New security standards should come into effect much faster. For fixes against attacks we know about today and new ones that are discovered and mitigated in the future.

▲

xyzzy123 3 days ago | parent | next [-]

People who care deeply about this can use 30 day certs right now if they want to.

▲

dextercd 3 days ago | parent [-]

Sure, but it's even better if everyone else does too, including attackers that mislead CAs into misissuing a cert.

CAs used to be able to use WHOIS for DCV. The fact that this option was taken away from everyone is good. It's the same with this change, and you have plenty of time to prepare for it.

▲

xyzzy123 3 days ago | parent [-]

> including attackers that mislead CAs into misissuing a cert.

I thought we had CT for this.

> CAs used to be able to use WHOIS for DCV. The fact that this option was taken away from everyone is good.

Fair.

> It's the same with this change, and you have plenty of time to prepare for it.

Not so sure on this one, I think it's basically a result of a security "purity spiral". Yes, it will achieve better certificate hygiene, but it will also create a lot of security busywork that could be better spent in other parts of the ecosystem that have much worse problems. The decision to make something opt-in mandatory forcibly allocates other people's labour.

	▲	dextercd 3 days ago \| parent [-]
		CT definitely helps, but not everyone monitors it. This is an area where I still need to improve. But even if you detect a misissued cert, it can not reliably be revoked with OCSP/CRL. -- The maximum cert lifetime will gradually go down. The CA/B forum could adjust the timeline if big challenges are uncovered. I doubt they expect this to be necessary. I suspect that companies will discover that automation is already possible for their systems and that new solutions will be developed for most remaining gaps, in part because of this announced timeline. This will save people time in the long run. It is forced upon you, and that's frustrating, but you do have nearly a year before the first change. It's not going down to 47 days in one go. I'm not saying that no one will renew certificates manually every month. I do think it'll be rare, and even more rare for there to be a technical reason for it.

▲

3 days ago | parent | prev [-]

[deleted]

▲

sidewndr46 5 days ago | parent | prev [-]

According to the article:

"The goal is to minimize risks from outdated certificate data, deprecated cryptographic algorithms, and prolonged exposure to compromised credentials. It also encourages companies and developers to utilize automation to renew and rotate TLS certificates, making it less likely that sites will be running on expired certificates."

I'm not even sure what "outdated certificate data" could be. The browser by default won't negotiate a connection with an expired certificate

▲

xyzzy123 5 days ago | parent [-]

> I'm not even sure what "outdated certificate data" could be...

Agree.

> According to the article:

Thanks, I did read that, it's not quite what I meant though. Suppose a security engineer at your company proposes that users should change their passwords every 49 days to "minimise prolonged exposure from compromised credentials" and encourage the uptake of password managers and passkeys.

How to respond to that? It seems a noble endeavour. To prioritise, you would want to know (at least):

a) What are the benefits - not mom & apple pie and the virtues of purity but as brass tacks - e.g: how many account compromises do you believe would be prevented by this change and what is the annual cost of those? How is that trending?

b) What are the cons? What's going to be the impact of this change on our customers? How will this affect our support costs? User retention?

I think I would have a harder time trying to justify the cert lifetime proposal than the "ridiculously frequent password changes" proposal. Sure, it's more hygenic but I can't easily point to any major compromises in the past 5 years that would have been prevented by shorter certificate lifetimes. Whereas I could at least handwave in the direction of users who got "password stuffed" to justify ridiculously frequent password changes.

The analogy breaks down in a bad way when it comes to evaluating the cons. The groups proposing to decrease cert lifetimes bear nearly none of the costs of the proposal, for them it is externalised. They also have little to no interest in use cases that don't involve "big cloud" because those don't make them any money.

	▲	dextercd 4 days ago \| parent [-]
		"outdated certificate data" would be domains you no longer control. (Example would be a customer no longer points a DNS record at some service provider or domains that have changed ownership). In the case of OV/EV certificates, it could also include the organisation's legal name, country/locality, registration number, etc. Forcing people to change passwords increases the likelihood that they pick simpler, algorithmic password so they can remember them more easily, reducing security. That's not an issue with certificates/private keys. Shorter lifetimes on certs is a net benefit. 47 days seems like a reasonable balance between not having bad certs stick around for too long and having enough time to fix issues when you detect that automatic renewal fails. The fact that it encourages people to prioritise implementing automated renewals is also a good thing, but I understand that it's frustrating for those with bad software/hardware vendors.