A user should not experience an expired certificate. Hence, the right UX is: null.
What's the right UX for an expired certificate?
31–40 of 105 posts
Re: What's the right UX for an expired certificate?
#32My 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…
I'm using strong protection in Chrome and it prevents me from browsing HTTP websites unless I explicitly allow it.
So while you're correct, it's just a historic issue and soon browsers will treat HTTP like bad HTTPS but not in a sense you're proposing but rather forbid both.
Re: What's the right UX for an expired certificate?
#33My 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?
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.
Re: What's the right UX for an expired certificate?
#34My 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…
> 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, do this without the browser talking to some "mothership" to ask about what a domain should be treated us because that would leave that party in a position where it gets to all of your browsing history.
Re: What's the right UX for an expired certificate?
#35My 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…
> 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 self-signed certificate is somebody claiming "trust me, I'm a bank manager" despite being unable to prove any association with your bank. And somebody with an expired ID might be a former, disgruntled employee whose ID has expired because they don't work there anymore. Both of those are far more suspicious than somebody not claiming to be anything in particular.
> 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.
That's not really reliable. The moment you install that as a norm, you'll have various countries doing MITM and generating their own cert for the site. Any confidence such a scheme provides is extremely suspect, as it relies on nobody exploiting the flaw for personal benefit.
> Also, a user should be able to trust a specific cert once on first visit, and then be warned only if that cert changed.
That only works if you think your attack mode is a hacked/malicious access point at a cafe or hotel. If you're in a place like Russia or China the state has the resources to ensure you always get the same MITM-ed cert, unless you play games with VPNs, which may well land you on some sort of watch list.
Re: What's the right UX for an expired certificate?
#36Is there a better way for dealing with certs? Would a very very long expiry date be better, and a bigger emphasis put on being able to invalidate them? The number of times "it's always the certificate" pops its head up after an outage is on the increase (when it's not DNS or BGP!) :-)
I think the opposite. A short expiry time ala LetsEncrypt, but with a process to "adopt" the new certificate. That is, the website can say, "I'm using this cert now, soon I'll be using that one".
Then the browser can be more strict with warning of unscheduled cert changes, and an expired-but-adopted cert is not a big issue and browsers don't have to be so alarmist about it.
Re: What's the right UX for an expired certificate?
#37No 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
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.
Re: What's the right UX for an expired certificate?
#38My 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…
> 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…
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.
Re: What's the right UX for an expired certificate?
#39My 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…
LetsEncrypt is not the only ACME provider, and there are hundreds of regular CAs. Nothing about TLS certificates is centralized, there's just market concentration as a result of good UI/UX by LetsEncrypt, but there are open-source ACME implementations available, the protocol itself is in the process of being standardized and nothing keeps other CAs from running the same service, and in fact many are planning to do ju…
>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.
Re: What's the right UX for an expired certificate?
#40Is there a better way for dealing with certs? Would a very very long expiry date be better, and a bigger emphasis put on being able to invalidate them? The number of times "it's always the certificate" pops its head up after an outage is on the increase (when it's not DNS or BGP!) :-)
We seem to be moving into the opposite direction, actually.
People fail to renew them because it is a very infrequent thing. At one point you could get certificates that were valid for five years. This was reduced to three, and is now even down to one year. If it is that infrequent, renewing the certificate becomes an ad-hoc thing, which is most likely poorly documented and easily forgotten about.
On the other hand, LetsEncrypt certificates are valid for 90 days, and I believe they want to make that even shorter. At that point the only viable way to deal with certificates is to set up tooling that will automatically renew it, solving the entire expiry issue in the process.