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

81–90 of 105 posts

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

#81

Post by AnIdiotOnTheNet »

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…

> Availability and resilience to failure are key pillars to security that are often overlooked.

In my experience, it cannot be overstated how true this statement is.

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

#82

Post by entropyie »

lucideer wrote: post #79
entropyie wrote: post #75

Earlier quoted context omitted.

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 & h…

A local proxy in this analogy would have to be able to MITM the traffic... which is unlikely to work with an Alexa. I'd like to see the EU mandate customer configurable CA bundles, but I won't hold my breath! --- https://www.dialgizmo.com/ A bit finicky, but does what is says on the tin ;-)

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

#83

Post by indymike »

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…

I think what you are saying is that expiration is important. The reasoning "cryptography is razor sharp" is really hard to follow. Cryptography is precise, but what really would help people is understanding why expiration dates matter so much. Most people carry a driver's license, and have to renew it. We all know that nothing magically happened that day to change anything about the driver - so that expiration is bureaucratic. Why is the expiration date on a cert different?

The layers of bureaucracy is a barrier to adoption of better security practices, and is all of our problem because at some point, you are using someone's website or api that is insecure because someone had to get one more approval or get someone to click one more button and did not.

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

#84

Post by peoplefromibiza »

lucideer wrote: post #61
entropyie wrote: post #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…

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

> http:// is just legacy baggage we should work toward getting rid of.

I, the server, should decide what protocol to use, not the client i.e. some software provided by two of the largest World corporations, which are also, by sheer accident I suppose, American.

I can send encrypted content over that insecure channel that only some receiver could decrypt and read.

It's none of Google's or Apple's business like it wasn't Microsoft's business to impose their browser and their standards on all of us.

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

#85

Post by jeroenhd »

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…

Your 45 year old rotary telephone could also have encrypted the numbers you're dialing. Buying user-hostile devices is what leads to user-hostile behaviour.

Apps needing to opt into CA certificates are an annoyance for sure but in 45 years the API those apps are talking to won't be running anyway. You'll still be able to buy WiFi adaptors for whatever tech we'll use by then to physically hook up your current devices, but the network itself won't work unless you set up a server for yourself.

Your converter box is similarly difficult, an old "speaker hooked up to a wire" protocol has been converted into a fully fledged Internet appliance. The POTS services that the phone wants to connect to are no longer there, you need to spoof them; the same will be true for the smart crapware we buy today.

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

#86

Post by jeroenhd »

nisegami wrote: post #39
ThePhysicist wrote: post #30

Earlier quoted context omitted.

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.

Most big apps bundle their own certificates/certificate authorities for cert pinning already. They can switch to their own CA system any time.

Sadly, DANE has failed because DNSSEC has failed on the American market. Hopefully we'll find an alternative for these protocols in the future.

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

#87

Post by lucideer »

entropyie wrote: post #82
lucideer wrote: post #79

Earlier quoted context omitted.

> 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 & h…

A local proxy in this analogy would have to be able to MITM the traffic... which is unlikely to work with an Alexa. I'd like to see the EU mandate customer configurable CA bundles, but I won't hold my breath! --- https://www.dialgizmo.com/ A bit finicky, but does what is says on the tin ;-)

If the definition of "older hardware" is closed saas-supported media products then I guess this is a different discussion than I thought. I'd be surprised if the SaaS support lifespan of things like Alexa would even be long enough for the hardware to be in any way usable after reaching an age considered "old" but... if it does, then I'd suggest the sibling commenter's point about selection criteria fits here.

> * I'd like to see the EU mandate customer configurable CA bundles*

Agree but I'd go broader - right to flash or some kind of general firmware/os/softwate openness mandate would be nice to see.

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

#88

Post by peoplefromibiza »

tialaramex wrote: post #26
andirk wrote: post #18

Earlier 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?

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

> How can we (and everybody else) agree on the identity of something?

we do, I rephrase it, billions of people do it all the time everyday on WhatsApp.

It's called TOFU

The first T means Trust.

Another example: Protonmail, it uses PGP, it works.

The important thing for privacy is the encryption part, not the identity part.

Even more so when we all know that full fledged HTTPS site put TENS OF MEGABYTES of garbage on their web pages to track people.

Identity: I want it confirmed if I'm talking to my bank, but why the bank cannot buy a 10 year certificate it's a mystery to me, I sure hope they'll still be in business in 10 years time from now, at least they should be able to not think about this minutia so often.

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

#89

Post by jeroenhd »

entropyie wrote: post #25
SturgeonsLaw wrote: post #22

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

> "This is the first time you have visited this page. Identity is not verified. Trust identity?"

Users will click random buttons until the popup disappears. You can watch it happen in real time when you help the elderly with computer issues and don't say anything. Every option from cancel to close to OK is tried as whatever is happening doesn't work. Reading the error message itself is an action of last resort.

There's a good reason you can only bypass certain TLS errors by typing "thisisunsafe" into the error screen in Chrome; people just clicked the ignore button until the problem disappeared and then ran into trouble.

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

#90

Post by jandrese »

dale_glass wrote: post #35
entropyie wrote: post #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…

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

I’ve always found it weird that expired certs are treated like a doomsday scenario by the browser. Technically they aren’t valid, but if it is just because they timed out the level of threat seems low. The only danger is that they might have been on a CRL that also trimmed the certs when they expired. In practice CRLs are barely used.
Post reply on HN