Live data from Hacker News

What's the right UX for an expired certificate?

emilymstark.com

51–60 of 105 posts

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

#51

Earlier quoted context omitted.

> 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 think part of the issue was that priorities shifted. Initially, SSL was for commerce. You were looking for assurance that your credit card number wouldn't be captured in flight, and would go to the right, verified party. In this context, a s…

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…

> 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.

I think it would be initially better, then gradually become worse. And that's a horrible thing when the public is concerned.

There's still people out there concerned about the "memory effect" for battery charging, and recommending a full discharge every time, even though that advice has been obsolete for decades now due to different battery chemistries. But the public easily latches on simple advice and doesn't consider the technical reasons for it.

So I imagine the same would be the case here. You'd have a marginal improvement for a short time, until the situation changes and suddenly people have to absorb "Yes, this was fine in 2023, but now is a complete no-go in 2026".

Since we're considering UX here. What UX do you propose that would reliably tell my nigh computer illiterate mom what to do with "the self-signed certificate for this site changed" if she receives it at a hotel while traveling? And what if she first opens the site in a hotel abroad, then comes back home and gets it there? How are non-experts supposed to untangle that?

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

#52
post #34

Earlier quoted context omitted.

> 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. How would a browser know whether a site presenting a self-signed cert is one where no strong claims of identity or privacy are needed or whether it's one where strong claims of identity are needed but which has been MitM'd. Also, d…

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?

DNS can be MitMd. crt.sh would be in a position to get all your browsing history.

The local thing would work, but of course only for local hosts.

It would not be worse than using plain http and my personal opinion is that visiting a plain http site should have the same UX as visiting a self-signed one.

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

#53
post #37

Earlier quoted context omitted.

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

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 s…

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

medical licenses don't arbitrarily expire every 3 months.

But anyway it's funny that medical licenses expire in some place.

Once a doctor, you're always a doctor, unless you do something wrong with your license and it gets revoked.

An expired license doesn't make your skills useless or you less capable.

If I had a stroke on the streets I would certainly trust a doctor to help me, even if the his license is expired (again, who let medical licenses expire? not even in USSR medical profession was so bureaucratic!)

Who gave the issuer of the certificates and the browser's vendors the right to decide if I can or can't _visit a website_ that has an expired cert?

and what's the matter?

we accept E2E encryption on chats that use TOFU, but we should "fuck off" web sites with an expired cert that hasn't changed, it's not been revoked, is exactly the same as before, providing the same level of security of before?

I don't understand this fixation, unless a lot of people make a lot of money out of this madness.

I mean , we all know that rotating passwords don't improve security, but suddenly making cert expire does?

silly.

> Renewing certificates isn't exactly rocket science

people make mistakes, problems arise, if I need that website now and it's not available because CHROME or FIREFOX or SAFARI chose so, it's a problem for me.

I'm not a baby, I'm an adult.

I can't count how many times that particular piece of information I was looking for was hosted on an old website that's only accessible via HTTP (another thing security zealots don't want you to use) or had an expired certificate.

Let me take my risks and give me a way to disable your bike wheels, I'm not Google's son.

And seriously, the entire f*king HTTPS business cannot rely on a non profit USA org, sponsored by all the usual suspects.

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

#54
post #43

Earlier quoted context omitted.

"The doctor is two minutes late, therefore all appointments today have been cancelled."

"The doctor's malpractice insurance expired yesterday, therefore the doctor cannot risk seeing you today even for this very routine appointment."

> The doctor's malpractice insurance expired yesterday

certs are not malpractice insurances though, they simply say that who you say are is who you say you are, which doesn't change when the cert expires.

Ids expire only to remind people to update their personal data and the picture on them.

And to remind the State to do a bit of background check once in a while, but even passports last 10 years.

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

#55
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.

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.

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

#56

Earlier quoted context omitted.

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…

> 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. I think it would be initially better, then gradually become worse. And that's a horrible thing when the public is concerned. There's still people out there concerned about the "memory effect" for battery charging, and recommending a full dis…

What kind of router, raspPI or kitten blog will you Mom be visiting at the hotel that would be of any importance? As I said, I wouldn't suggest allowing this scheme for anything important, such as Google, banks etc...

To answer your question, I don't think the TLS cert should ever change for these kinds of non-identity certs. if they do, the standard warning can apply.

My point is that there should be an escape hatch to provide resilient solutions to narrowly defined use cases, such as hobby websites, wifi routers etc... that don't trains users to bypass security control like the current scheme does.

Right now, if I want my Mom to configure her Huawei wifi router, she has the choice between sending her password in plain-text to a trivially spoofed website, or being trained to ignore TLS warnings and overriding those warnings in her browser, before sending her password into a still-spoofable website.

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

#57

Earlier quoted context omitted.

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…

> 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. I think it would be initially better, then gradually become worse. And that's a horrible thing when the public is concerned. There's still people out there concerned about the "memory effect" for battery charging, and recommending a full dis…

Also, today, if your Mom visits google.com, for the first time, and the hotel blocks port 443... guess what? It will try to connect to google.com using HTTP on port 80... at which point the hotel can inject whatever they like.

In terms of UX, in my scenario, if they "really" wanted to, the browser could fake a HTTP:// scheme along with the crossed out lock icon, effectively identical to the status quo in terms of UX, but with improved (not perfect) privacy.

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

#58
post #52

Earlier quoted context omitted.

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?

DNS can be MitMd. crt.sh would be in a position to get all your browsing history. The local thing would work, but of course only for local hosts. It would not be worse than using plain http and my personal opinion is that visiting a plain http site should have the same UX as visiting a self-signed one.

All fair points, and I would settle for HTTP equivalent UX. DOH and DOT would go some way to mitigating DNS inadequacies (although they have their own issues in terms of network autonomy). I personally think the best long term solution would be for each TLD to maintain the CA bundle and TLS standards for that TLD. That way there is no case where a CA cert from CN can issue a cert for google.com .

It would also specifically allow non-identity locally issued certs for .local, .lan, .hobby etc...

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

#59

Earlier quoted context omitted.

> 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. I think it would be initially better, then gradually become worse. And that's a horrible thing when the public is concerned. There's still people out there concerned about the "memory effect" for battery charging, and recommending a full dis…

Also, today, if your Mom visits google.com, for the first time, and the hotel blocks port 443... guess what? It will try to connect to google.com using HTTP on port 80... at which point the hotel can inject whatever they like. In terms of UX, in my scenario, if they "really" wanted to, the browser could fake a HTTP:// scheme along with the crossed out lock icon, effectively identical to the status quo in terms of UX,…

I expect that to go away eventually, by browsers simply not allowing HTTP for non-local requests. This means a hotel doing this looks like one where wifi just doesn't work.

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

#60

Earlier quoted context omitted.

> 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. I think it would be initially better, then gradually become worse. And that's a horrible thing when the public is concerned. There's still people out there concerned about the "memory effect" for battery charging, and recommending a full dis…

What kind of router, raspPI or kitten blog will you Mom be visiting at the hotel that would be of any importance? As I said, I wouldn't suggest allowing this scheme for anything important, such as Google, banks etc... To answer your question, I don't think the TLS cert should ever change for these kinds of non-identity certs. if they do, the standard warning can apply. My point is that there should be an escape hatch…

> What kind of router, raspPI or kitten blog will you Mom be visiting at the hotel that would be of any importance? As I said, I wouldn't suggest allowing this scheme for anything important, such as Google, banks etc...

That is part of the problem. How is she supposed to know what's okay or not in what context?

The simplest answer that ensures security as well as we can is to simply not give the user any options. Everything must be encrypted, nothing can be self-signed, plain HTTP support is disabled.

> Right now, if I want my Mom to configure her Huawei wifi router, she has the choice between sending her password in plain-text to a trivially spoofed website, or being trained to ignore TLS warnings and overriding those warnings in her browser, before sending her password into a still-spoofable website.

I think that's solvable, and may have already been solved.

I think current ASUS routers already contain a valid certificate for something like router.asus.com, and the router responds to HTTPS on that address. Or something along those lines, I've not really interacted much with it.

But the point is that in such a scheme, the router would contain a valid cert, issued by a valid authority.

Post reply on HN