It’s a complete failure of infosec-meets-user-psychology that “this TLS certificate is issued for your bank and the server is sneaky hackerman dot com” and “this otherwise valid certificate expired a day ago” have the EXACT SAME USER EXPERIENCE.

@Quinnypig I have been beating this drum for years, at browser companies keep making it *worse*, not better.

An expired cert should, at worst, be like, a yellow warning in the address bar for a month or two. There's *zero* justification for treating a barely expired certificate as a reason not to navigate to a page.

Worse yet is the absolute travesty that is HSTS, which then ensures you can't bypass the error for any reason, even if you understand why it happened.

@ocdtrekkie @Quinnypig

Expired certs *have to* be treated exactly the same as revoked certs for two reasons, imo:

1) No one revokes certs after they expire. If a cert should be revoked (e.g. due to key compromise) shortly after it expires, it just won't be revoked instead. The browser must assume all expired certs may have been revoked, too.

2) If certs are allowed to function after they expire, the WebPKI loses agility. Enforcing expiry is how browsers ensure that BRs changes take effect.

@asg @Quinnypig

2) WebPKI is mostly complete garbage and an embarrassment to the industry to begin with. Agility is another word for "fragility".

1) Is this a real world scenario, where you have ever experienced a security issue with a certificate which expired in less than a month?

Meanwhile: https://betanews.com/2022/03/22/81-percent-of-organizations-have-outages-caused-by-expired-certificates/

Which is to say, certificate nerds' theories are being used to justify massive real world damage.

81 percent of organizations have outages caused by expired certificates

A new report shows that 81 percent of organizations have experienced at least two or more disruptive outages caused by expired certificates in the past two years, up from 77 percent last year.

BetaNews
@asg @Quinnypig Don't get me wrong, Let's Encrypt is great at removing the highway robbery that was charged for a fundamentally useless layer of business process to generate a random number, thanks for that, but neither DV nor hard 12 month cert rotation requirements are meaningfully making anyone more secure.
@asg @ocdtrekkie @Quinnypig expired certs “drop off” CRLs (in most circumstances, code signing is one of the few usages where a cert with that key usage WON’T drop off a CRL.) Expiry of a certificate is checked (according to RFC 5280) PRIOR to revocation checking. Hence why expiry is considered “terminal” in terms of certificate validity.

@markpx509v3 @asg @Quinnypig Is this a practical concern or a theoretical one? My understanding is CRL checking not exactly ironclad to begin with. But the practical risk of expired certs appears to be still effectively nonexistent.

Can you give me an example of a real world attack that was done involving an expired certificate?

@ocdtrekkie @markpx509v3

It's practical. The specifics of CRLs vs OCSP vs any other revocation checking mechanism don't matter; what matters is that a cert which *otherwise* would be revoked, in fact won't be, simply because it is already expired.

The easiest attack vector is:
- issue a cert for example.com, let it expire
- sell example.com to someone else. They revoke all extant certs, but don't revoke yours because it's expired.
- intercept their traffic, and use your expired cert for TLS

@ocdtrekkie @markpx509v3 So if you want expired certs to be trusted by browsers, you have to let expired certs be revoked. If you want to let expired certs be revoked, you have to change the Baseline Requirements, every existing CRL and OCSP implementation, and x509 itself. That's impractical.

Fundamentally, browsers have to choose *some* time to start treating an expired cert as equivalent to a revoked cert. The instant it expires is as good as any other time, and better than most.

@asg @markpx509v3 You can already request a valid certificate that's good for a year, and sell a domain to someone immediately thereafter, can you not? There's 364 days of valid certificate.

The instant is expires is absolutely the worst time to start treating an expired cert like a revoked cert, aforementioned 81% of organizations negatively impacted by issue caused solely by theoretical risks not used in practical attacks ever.

@ocdtrekkie @markpx509v3 Yes, but they can revoke that cert by virtue of controlling the domain name on it (revocation reason CessationOfOperation). CAs are required to respect this request by the BRs. They are no longer required to do so once the cert expires.
@asg @markpx509v3 Beyond the general issue of causing widespread issues solely based on PKI being designed by people who literally hate users, instantly rejecting expired certs has (rightfully) taught me to completely ignore browser cert warnings, and bypass nearly all of them by default.

@asg @markpx509v3 This has never gotten me to a bad place, so why would I ever stop? (Since this conversation started, I clicked a link on HP's website, which linked to a subdomain where their cert was expired a week ago, and I clicked through, and it in turn redirected me back to an HP site with a valid cert. I literally experience things like this... close to daily?)

I at least know the potential risks, but most people will both bypass these inane warnings while not understanding the risks.

@ocdtrekkie @markpx509v3 I guess I don't know what to say. I've worked in this field for a while now and in tech generally for much longer, and I have *never* clicked through an expired cert warning and refusing to do so has never negatively affected my experience.

Browsers blocking these sites works. Choosing to block them a day, a week, or a month after they expire simply kicks the can down the road.

Convince site operators to automate their issuance, not browsers to reduce user security.

@asg @markpx509v3 The thing is, the PKI structure doesn't actually increase user security. None of this nonsense has come from practical attacks.

And aren't we amongst the process of yet another of those highly vetted CAs getting distrusted for... never having been trustworthy to begin with?

Why do browsers trust a certificate signed for a US company in China more than a certificate that expired yesterday?

@asg @markpx509v3 I absolutely would have regular issues if I was scared to bypass a cert warning: They regularly impede my access to otherwise perfectly functional parts of the web, often to resources I need to do my job.

There's also basically no real world threat in doing so. Even "wrong domain" errors are exclusively misconfigurations in practice.

Automated issuance is great, but we're about a decade from when you can assume that's possible for all things.

@asg @markpx509v3 Also, domain validation isn't drastically good at proving to a human that the destination is trustworthy. Eventually when people figure out that security doesn't scale, we'll need a new flavor of Extended Validation (Verified Mark certificate, I guess is what we're going with for them now?)

And then we'll need a whole pile of new specs to determine if a site that uses DV instead of EV should be believed as secure on a given site or whatever. And it won't be automated. *shrug*

@ocdtrekkie Of course the WebPKI increases user security. Does it increase it *as much as one might hope*? No. But does it increase security over transmitting everything in plaintext, or having absolutely zero basis on which to make key trust decisions? Of course it does.

Since you're throwing around hyperbole instead of having a serious conversation about the pain points and merits of specific aspects of the current WebPKI, I'm muting this thread.

@ocdtrekkie @asg @markpx509v3 this is the exact scenario I point out in risk assessments when I find expired certs, along with things like "this cert expired a year ago, indicating a lack of site maintenance or monitoring." They're training end users to ignore potentially valid warnings. (Well, the browsers are training them in this case.)
@legion303 @asg @markpx509v3 Exactly. It's a case of alert fatigue, or a boy who cried wolf situation.