Live data from Hacker News

What's the right UX for an expired certificate?

emilymstark.com

11–20 of 105 posts

Re: What's the right UX for an expired certificate?

#11
post #8

Just this week I had an issue with a Letsencrypt cert that wasn't updated. All of my users had visited the site and the certificate was the same. Browsers should give a less dramatic response if they have already seen the certificate and it simply expired. It's completely different from visiting a new site whose certificate the browser has never seen.

[deleted]

Re: What's the right UX for an expired certificate?

#12

No completely and super hard disagree. An expired certificate is not a negotiable or "soft" error. What the hell is wrong with people today? It's not rocket science. Get your shit together or fuck off for the sake of everyone else. Nobody cares about all the layers of bureaucracy between you and renewing that cert. That's your fucking problem. Seriously no joke. Stop making this a "mere implementation detail" and you…

I know you're being downvoted for the tone, but I agree entirely. Security is not something to sacrifice to gain less angry users. I do agree, however, with the sentiment that the UX surrounding security leaves a lot to be desired. In most cases we train users to ignore or work around security problems - we don't give them tools to solve and embrace them.

Re: What's the right UX for an expired certificate?

#13
My biggest issue with this whole situation, is that the user gets a better UX with no encryption whatsoever on a http:// site than a self-signed or expired cert on https://.

I know all the stories about MITM attacks, but the fact is, it is still MUCH easier to accidentally or purposefully log unencrypted http:// traffic in a passive manner than it is to actively spoof a HTTPS:// connection.

Especially for local LANs, but also for small websites, there should be a way to use TLS with a self-signed cert to say hey, I'm not making any strong claims of identity or privacy here, I just want some modicum of obfuscation of the traffic. Also, a user should be able to trust a specific cert once on first visit, and then be warned only if that cert changed.

Also, the fact that the entire world's infrastructure relies on some small, centralised non-profit in the USA (LetsEncrypt) makes me very nervous. Ordinary citizens can end up on the wrong side of sanctions through no fault of their own...

Re: What's the right UX for an expired certificate?

#14
We have a repeatable build environment at work. However we can't rebuild anything from 2017 or before anymore because the environment back then doesn't have any valid certificates to validate servers downloading artifacts from, or that the artifacts signed back then are correct. Thus our build environment fails to be repeatable for long because the old environment cannot be used or duplicated 100%.

Re: What's the right UX for an expired certificate?

#15
post #14

We have a repeatable build environment at work. However we can't rebuild anything from 2017 or before anymore because the environment back then doesn't have any valid certificates to validate servers downloading artifacts from, or that the artifacts signed back then are correct. Thus our build environment fails to be repeatable for long because the old environment cannot be used or duplicated 100%.

Yes, and extending this to devices with embedded PKI, we are leaving a very poor legacy to our progeny.

Look at all the amazing work being done to maintain old computers, software and games, from the 80's, like C64, NES, PDP-11, etc...

What will our descendents be able to maintain from this period? Not much.

Re: What's the right UX for an expired certificate?

#16
post #12

No completely and super hard disagree. An expired certificate is not a negotiable or "soft" error. What the hell is wrong with people today? It's not rocket science. Get your shit together or fuck off for the sake of everyone else. Nobody cares about all the layers of bureaucracy between you and renewing that cert. That's your fucking problem. Seriously no joke. Stop making this a "mere implementation detail" and you…

I know you're being downvoted for the tone, but I agree entirely. Security is not something to sacrifice to gain less angry users. I do agree, however, with the sentiment that the UX surrounding security leaves a lot to be desired. In most cases we train users to ignore or work around security problems - we don't give them tools to solve and embrace them.

[flagged]

Re: What's the right UX for an expired certificate?

#17

No completely and super hard disagree. An expired certificate is not a negotiable or "soft" error. What the hell is wrong with people today? It's not rocket science. Get your shit together or fuck off for the sake of everyone else. Nobody cares about all the layers of bureaucracy between you and renewing that cert. That's your fucking problem. Seriously no joke. Stop making this a "mere implementation detail" and you…

imagine applying the same medicine to other situations.

- you're two minutes late, your appointment has been canceled

- but I am here for the chemio. I drove 100 miles to be here.

- Get your shit together or fuck off for the sake of everyone else. Nobody cares about all the layers of bureaucracy between you and being on time. That's your fucking problem

Re: What's the right UX for an expired certificate?

#18

My biggest issue with this whole situation, is that the user gets a better UX with no encryption whatsoever on a http:// site than a self-signed or expired cert on https:// . I know all the stories about MITM attacks, but the fact is, it is still MUCH easier to accidentally or purposefully log unencrypted http:// traffic in a passive manner than it is to actively spoof a HTTPS:// connection. Especially for local LANs…

Good point! No encryption shows zero issue.

Your mention of us all using LetsEncrypt and similar is beyond my understanding of cryptography but why do they need to be signed by a central authority exactly?

Re: What's the right UX for an expired certificate?

#19
post #18

My biggest issue with this whole situation, is that the user gets a better UX with no encryption whatsoever on a http:// site than a self-signed or expired cert on https:// . I know all the stories about MITM attacks, but the fact is, it is still MUCH easier to accidentally or purposefully log unencrypted http:// traffic in a passive manner than it is to actively spoof a HTTPS:// connection. Especially for local LANs…

Good point! No encryption shows zero issue. Your mention of us all using LetsEncrypt and similar is beyond my understanding of cryptography but why do they need to be signed by a central authority exactly?

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.

Re: What's the right UX for an expired certificate?

#20

No completely and super hard disagree. An expired certificate is not a negotiable or "soft" error. What the hell is wrong with people today? It's not rocket science. Get your shit together or fuck off for the sake of everyone else. Nobody cares about all the layers of bureaucracy between you and renewing that cert. That's your fucking problem. Seriously no joke. Stop making this a "mere implementation detail" and you…

imagine applying the same medicine to other situations. - you're two minutes late, your appointment has been canceled - but I am here for the chemio. I drove 100 miles to be here. - Get your shit together or fuck off for the sake of everyone else. Nobody cares about all the layers of bureaucracy between you and being on time. That's your fucking problem

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".
Post reply on HN