Is 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!) :-)
What's the right UX for an expired certificate?
21–30 of 105 posts
Re: What's the right UX for an expired certificate?
#22My 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
Well, there is, all (afaik) current browsers have some kind of barely visible "yeah, I know, take me there any way" button buried under a click or two on those cert error screens. The only exception to this that I can recall are servers that use an old version of TLS like 1.0, and in those cases, there is a browser flag that lets them load.
Re: What's the right UX for an expired certificate?
#23Earlier 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
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".
"The doctor is two minutes late, therefore all appointments today have been cancelled."
Re: What's the right UX for an expired certificate?
#24No 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…
An expired certificate _is_ a soft error, and in most cases nobody gives a fuck. For example, if HN's certificate expired and my browser absolutely prohibited access to it on the basis of that, I'd switch browsers because there's 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. I literally don't care if someone can read the blog entry as I download it from its publicly-accessible URL.
On the other hand, if my e-mail provider's certificate is expired, there's a little more at stake, and there are other services where the HTTPS security being broken can cost me money. Those I do care about.
Re: What's the right UX for an expired certificate?
#25My 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 Well, there is, all (afaik) current browsers have some kind of barely visible "yeah, I know, take me there any way" button buried under a click or two on those cert error screens. The only exception to this that I can recall are servers that use an old version of TLS like 1.0, and in those cases, there is a browser flag that lets them load.
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 ;-)
Re: What's the right UX for an expired certificate?
#26My 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?
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.
Re: What's the right UX for an expired certificate?
#27Earlier quoted context omitted.
> there should be a way to use TLS with a self-signed cert Well, there is, all (afaik) current browsers have some kind of barely visible "yeah, I know, take me there any way" button buried under a click or two on those cert error screens. The only exception to this that I can recall are servers that use an old version of TLS like 1.0, and in those cases, there is a browser flag that lets them load.
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…
For 90% of people there's two UI options
1) a button to let them get where they want to go
2) A button which doesn't let them get where they want to go
Re: What's the right UX for an expired certificate?
#28Earlier quoted context omitted.
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 wa…
It would be interesting to see governments or domain registries set up ACME-compatible CAs.
At the moment, it looks like there are options in Norway and Austria as well as the US: https://www.xf.is/2020/06/30/list-of-free-acme-ssl-providers...
Re: What's the right UX for an expired certificate?
#29My 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?
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.
Re: What's the right UX for an expired certificate?
#30My 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 just that.