Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's the right UX for an expired certificate?

emilymstark.com

Post reply on HN
Print view View original

71–80 of 105 posts

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

#71

Post by lazyweb »

forinti wrote: 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.

On the other hand, especially when offering an online service, cert monitoring and/or robust automation are essential. Blaming browser behaviour is missing the point in my opinion.

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

#72

Post by faeyanpiraat »

lisper wrote: post #69

Wow, the tone of the discussion here is, um, disappointing. I see people defending two extreme positions, both of which are indefensible, and no one (so far) actually tackling this problem in any kind of constructive way. On the one side, there are the people who say that an expired cert should be a hard error because security is too important for any kind of compromise. On the other side there are people saying that…

Nothing is safe without SSL (expired or not), if you are on public WIFI.

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

#73

Post by entropyie »

lisper wrote: post #69

Wow, the tone of the discussion here is, um, disappointing. I see people defending two extreme positions, both of which are indefensible, and no one (so far) actually tackling this problem in any kind of constructive way. On the one side, there are the people who say that an expired cert should be a hard error because security is too important for any kind of compromise. On the other side there are people saying that…

Most of my comments mention the fact that the escape hatch should be limited to certain use cases, such as local networks, certain TLDs etc...

Tying the validation requirements and CA bundle to the TLD would be a useful strategy and would in fact increase security in most cases.

For example imagine the official Chinese government CA can only issue certs for .cn . The TLD could also mandate TLS v1.3 and the latest crypto algorithm.

This simultaneously protects the Chinese from Western interference, and Google from Chinese interference.

"Encryption only" never-expiring certs could be specifically banned for .com .bank etc... but allowed for .local, .lan, .hobby and plain IP addresses.

This increases security across the board without sacrificing autonomy.

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

#74

Post by jen20 »

entropyie wrote: post #67
lucideer wrote: post #61

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 that's a well-acknowledged issue but those who disagree on less-severe expiry warnings would simply argue here that it would be preferable to be strict in both cases and that the lax approach to http:// is just legacy baggage we s…

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…

> without requiring the blessing and grace of a distant 3rd party authority.

Nothing stops you installing a private CA into the trusted roots for this kind of case.

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

#75

Post by entropyie »

jen20 wrote: post #74
entropyie wrote: post #67

Earlier quoted context omitted.

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…

> without requiring the blessing and grace of a distant 3rd party authority. Nothing stops you installing a private CA into the trusted roots for this kind of case.

Here is a thought experiment for you: Right now, I have a 45 year old rotary telephone working fine in my living room, hooked up to VOIP with an adaptor.

In 40 years time, how will anyone be able to make use of my "antique Internet Radio / Amazon Alexa"?

Virtually zero appliances / embedded systems sold today allow you to configure the CA bundle. Even Android is locking this down bit by bit as they don't want anyone peeking at all the surveillance traffic their Apps are sending to the internet.

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

#76

Post by jen20 »

oalae5niMiel7qu wrote: post #24
sublinear wrote: post #9

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…

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

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

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

#77

Post by lucideer »

entropyie wrote: post #67
lucideer wrote: post #61

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 that's a well-acknowledged issue but those who disagree on less-severe expiry warnings would simply argue here that it would be preferable to be strict in both cases and that the lax approach to http:// is just legacy baggage we s…

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…

> In the past 20 years, all of the critical failures in PKI systems that I have seen [...] None were due to [...] use of plain HTTP.

Not sure how a PKI failure specifically can be due to use of plain HTTP, but I assure you there's been plenty of other very real security failures over the past 20 years due to use of HTTP.

> That legacy baggage is the only thing that allows older hardware to connect to the modern network.

This sounds like legacy baggage, yes. The term "legacy" is not a value judgement. It doesn't mean "bad", it just means "old".

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

#78

Post by jen20 »

entropyie wrote: post #75
jen20 wrote: post #74

Earlier quoted context omitted.

> without requiring the blessing and grace of a distant 3rd party authority. Nothing stops you installing a private CA into the trusted roots for this kind of case.

Here is a thought experiment for you: Right now, I have a 45 year old rotary telephone working fine in my living room, hooked up to VOIP with an adaptor. In 40 years time, how will anyone be able to make use of my "antique Internet Radio / Amazon Alexa"? Virtually zero appliances / embedded systems sold today allow you to configure the CA bundle. Even Android is locking this down bit by bit as they don't want anyone…

Make that part of your purchase criteria if it matters to you.

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

#79

Post by lucideer »

entropyie wrote: post #75
jen20 wrote: post #74

Earlier quoted context omitted.

> without requiring the blessing and grace of a distant 3rd party authority. Nothing stops you installing a private CA into the trusted roots for this kind of case.

Here is a thought experiment for you: Right now, I have a 45 year old rotary telephone working fine in my living room, hooked up to VOIP with an adaptor. In 40 years time, how will anyone be able to make use of my "antique Internet Radio / Amazon Alexa"? Virtually zero appliances / embedded systems sold today allow you to configure the CA bundle. Even Android is locking this down bit by bit as they don't want anyone…

> Here is a thought experiment for you: Right now, I have a 45 year old rotary telephone working fine in my living room, hooked up to VOIP with an adaptor.

The adaptor in your analogy sounds like it could be analogised by a local transparent proxy.

A more apt formulation of the analogy would be phone companies persisting DTMF to avoid the need for adapters.

----

What adapter do you use? I also have a rotary phone & have been struggling to find a good one...

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

#80

Post by indymike »

The key to all of this is user awareness, and I'm not sure users care very much. I own a small payment processor, and we've researched this quite a bit: users only really care about if the little clock is present in the URL bar, and they leave if they get warning dialogs. All the other stuff, badges, changing the awesome bar color, have very little effect on users. Users are about 80% sensitive to interruptions that say "not secure" or something else scary.

There are a couple things about certs that are very much arbitrary: expiration date and any user input identification data. CAs try to deal with the identification data by doing some kind of validation, but that has decayed to what amounts to prove you control the domain by doing some trivial thing. Expiration dates, as currently set, serve to ensure that people have to renew their certificates, and prior to Let's Encrypt, this guaranteed recurring revenue for CAs. Expiration dates make sense to ensure that at some point, a compromised certificate would have to be replaced, but the way those dates are set is... very convenient for ARR.

Post reply on HN