What's the right UX for an expired certificate?

Ultimately every cert is signed by a Certificate Authority. This is a "Trust Anchor". An authority that you trust implicitly. Your web browser maintains a list of these trusted parties, which are measured in the dozens and only change occasionally after careful scrutiny by Browser vendors. If your cert is not signed by one of these CAs, there is no way to verify it's veracity. That is why the browser gives a scary warning. I could issue a cert claiming to be google.com without any deterance. Until recently all such authorities charged a fee to issue you a verified certificate. Also the process was usually not fully automated and required human intervention to renew a cert. LetsEncrypt was a major innovation for two reasons:

1. They provided the certificates for free, no strings attached 2. They provided a fully automated and optimized process to issue/renew/deploy the cert

This had the effect of making HTTPS accessible to everyone, and is the reason that HTTPS has become the default rather than only being used for a small fraction of websites (e-commerce etc...).

Overall this has been a positive development and has raised the bar against mass-surveillance across the world. However, the downside as mentioned, is that much of the world's infrastructure now relies on this small company. Since the certs are only valid for 3 months, any blockage in that renewal process means rapidly failing services.

The other answer to your question seemed to me to have guessed wrong what you're concerned about. My guess is that like a lot of non-experts, your thought was "Why do we need this CA role?" and that, fortunately, is something where I can appeal to your intuitions rather than needing some mathematical proof about cryptography you won't understand.

This is about identity. How can we (and everybody else) agree on the identity of something? Is "Chris Pratt" the movie guy we've both heard of, or is it some Belgian guy's friend's brother you met once at a party? The Screen Actors Guild insists its members all have distinct names so you can tell them apart. If your real name is Clint Eastwood and you go into acting, too bad change it or you won't be allowed to work on most stuff with union rules. You don't need a legal change of name (although if you're a serious actor you might decide it's less bother to get one) but you must use a name distinct from those already in use in the industry.

Naturally there can't be some objective "truth" to a name. People may say "She looks like a Deborah" but that's not really how it works - when we find someone in a coma with no ID we don't go "Oh, he looks like a Jim Smith, of 420 Springfield Crescent", we have to put out a public appeal with photos. If I show you a web page it may look like Wikipedia, but I can trivially do that myself, so the real Wikipedia is the one everybody agrees on, and if for some reason we all agreed tomorrow that's not Wikipedia, it wouldn't be.

So, with no objective truth† we have to instead have an authority, and for everybody's convenience we should all trust at least roughly the same authorities, so we're all agreed about who we're talking about

† We can use cryptography to "assign" things names, but these names aren't very satisfactory, that's how Tor's private services work, which is why they have ugly names like facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion -- notice that all those letters are crucial, facebookwkhpilnemxj7asaniu7vnjjxiltxjqhye3mhbshg7kx5tfyd.onion is one letter different and would be a different Tor service not operated by Facebook.

The CA signing provides different levels of validation. DV (Domain validation) certificates require demonstration of control over the dns record(s) to the CA, ensuring the (IP address) server responding to your request has demonstrated control of the domain name by which you addressed it, to the CA.

Let’s say your local dns is poisoned to resolve to a nefarious server at a specific IP address for ss64.com, that server’s certificate won’t be signed by a CA (unless they also controlled ss64.com’s dns records, in which case there would have be no need to poison your local dns). Your connection to this server can still be encrypted via a certificate, but the CA won’t be providing validation of their identity or affiliation with the real ss64.com.

TL;DR

It's just for Identification.

The signature on the public key matches what domain it should resolve, and said public key pairs with a private key that encrypts your data. Assuming you don't a) mishandle the private key, b) the Signatory has a reasonably process to assure that person with the private key should be able to encrypt the domain, and c) all potential trusted Signatories can be trusted, then you can reasonably assume the site you're visiting is legit.

The actual encryption doesn't need identification. Doing so would ensure others can't listen to your conversation, but wouldn't help if the person you think you're talking to isn't actually the right person. This is a realistic problem, because there's nothing in DNS or routing that ensures trust.

Sure, what I had in mind was a more user-friendly UX. For example, if I could add something to the certificate subject to say: "This is an obfuscation only cert, not claiming identity or MITM resistance".

Then, the browser would either show the address bar like a HTTP page, or maybe show a notification instead of a block page, saying: "This is the first time you have visited this page. Identity is not verified. Trust identity?"

You can tell I don't do UX for a living ;-)

>Nothing about TLS certificates is centralized

You're right that there are additional ACME providiers, but the reliance on just a handful of default root cert stores is what makes HTTPS centralized, even if TLS isn't.

The browser shouldn't, the user is the one that needs to make that determination. But right now, the user doesn't even have that choice.

DNS? crt.sh? Certificate Pinning? Apply this only to non-routable IPs? Apply this only to certain TLDs, such as: .local .lan .personal There are many options. Also, how would this be any worse than visiting a plain HTTP site instead?

Requiring a remote 3rd party to bless a transaction in order for two computers on a local network to talk to each other, is tyrannical and anti-resilient.

As I said, I am well aware of the perils of MITM. There are mitigations for all your concerns, and in each case, the question should be: is this better or worse than plan HTTP.

As I mentioned below, mitigations include: restricting this scheme to IP Addresses only, non-routable netblocks only, certain TLDs like .local, .lan .personal etc...

In regards to oppressive regimes, the state can also block all traffic unless you relent and install their CA cert in your browser bundle.

Mitigations here would be certificate transparency, pinning etc... I would also suggest that CA certs should be restricted to certain TLDs. Important websites can use all these mitigations, while still allowing my scheme for connecting to my Raspberry PI, kitten blog, or wifi router.

I’ve always found it weird that expired certs are treated like a doomsday scenario by the browser. Technically they aren’t valid, but if it is just because they timed out the level of threat seems low. The only danger is that they might have been on a CRL that also trimmed the certs when they expired. In practice CRLs are barely used.

That legacy baggage is the only thing that allows older hardware to connect to the modern network. It's the only thing that allows folks the agency and autonomy to setup their own services and share them with folks locally, without requiring the blessing and grace of a distant 3rd party authority.

I've spent 20 years working with advanced PKI and cryptography in many different domains and form factors, and what I've learned is that even with the best of intentions, they are all fragile and their default state is broken, without constant maintenance.

Availability and resilience to failure are key pillars to security that are often overlooked.

In the past 20 years, all of the critical failures in PKI systems that I have seen were due to expiring certs, expiring CRLs, failure to distribute new PKI in time, accidental deletion of key PKI, missing intermediate certs. None were due to MITM, weak crypto, spoofed packets, use of plain HTTP. Make of that anecdote what you will.

> http:// is just legacy baggage we should work toward getting rid of.

I, the server, should decide what protocol to use, not the client i.e. some software provided by two of the largest World corporations, which are also, by sheer accident I suppose, American.

I can send encrypted content over that insecure channel that only some receiver could decrypt and read.

It's none of Google's or Apple's business like it wasn't Microsoft's business to impose their browser and their standards on all of us.

It is probably easier to give a browser a fake DNS result (ie, a MITM attack) than to do the same to the letencrypt authorizers.

Fake DNS result/MITM is one of the things that the SSL cert is supposed to guard against. Possibly the only thing that a domain-validated cert has going for it over an anonymous cert. Allowing a domain cert to be "renegotiated" from the browser would seem to defeat the purpose of having a domain cert at all.

Disagree with your disagree. I understand there’s a recession and security people have to justify their salaries.

The most secure system imaginable is for your users to shut their computers and go outside. If you can’t provide security without usability, your system is worthless.

The truth is that users want products that feel secure, rather than products that are secure.

> Security is not something to sacrifice to gain less angry users.

Of course it is - it depends on Capital-C-Context.

Sure, for the bank, the site you are supplying your credit card details, your email, etc - security is non-negotiable.

For hackernews, for reddit, and for similar sites, then security is something to sacrifice, once again depending on context.

I've trusted this certificate for the last 2, maybe 3 years. It's unreasonable to assume that 5 minutes past midnight on the expiry date, the cert turned from "completely trustworthy" to "100% certainty that this is a phish, scam or similar".

We live in the real world. Things happen.

Here's the thing: Expired certificate warnings reduce security. Because they're excessively dramatic about a routine non-issue, people learn to ignore and bypass them. Now people won't head real certificate warnings.

Unfortunately, the browser security nerds don't understand human psychology, and are more scared of the fact an expired cert can't be revoked (a nearly pointless edge case) versus users ignoring all cert warnings entirely, which they do now. A classic example of engineers who don't understand their users.

That analogy is a bit off because the certificate problem is on the supplier's side, not the customer's. A more apt analogy would be "no you can't see the doctor today, because their passport expired yesterday".

How about a

- Your doctor let their medical license lapse. They are legally not allowed to practice medicine until they renew it.

or a

- The hospital did not pass its mandatory inspection. We are not allowed to practice medicine here until we redo the inspection and pass it.

?

Renewing certificates isn't exactly rocket science. It's not an oopsie-whoopsie, it is a pretty massive ops failure and should be treated as such.

> literally nothing at stake if somebody is able to read my traffic to or from this unimportant site.

> There's even less at stake when it comes to the cryptographic security of some blog.

This would only be the case if ISPs were not adversarial. In the US - for most people - They are, though.

Well, the debugger is a good example, because it’s also not something that concerns the end user, but only the developer.

In the same way, certificate expiration is a problem that can easily and with 100% reliability be handled by operations. A end user should never be confronted with it.

Isn’t that what happens now when the cert expires? Except when it’s expired it’s a lot harder for users to figure out how to bypass the warnings so they can visit the site to find a contact link to report the issue.

Remember not every site is actively checked by their maintainer every day.

In an ideal world it shouldn’t be needed (and likewise UX for expired certs wouldn’t be needed), but in practice I think it has merit.