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

61–70 of 105 posts

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

#61

Post by lucideer »

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 should work toward getting rid of.

Personally, I'm a little on the fence. The expiry UX could definitely be "improved" (made more helpful) without making it more lax. Another thing to consider is that going from lax to strict is MUCH MUCH harder than going from strict to lax, so easing severity now would make it difficult to undo that change later.

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

#62

Post by bombcar »

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…

Especially since all Let’s Encrypt cares about us a DNS proof-of-domain, it should be possible to negotiate that from the browser itself.

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

#63

Post by mLuby »

dale_glass wrote: post #51
entropyie wrote: post #49

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…

> There's still people out there… recommending a full discharge every time, even though that advice has been obsolete for decades

The battery UX should hide this implementation detail from the user. If 20/80% is 0/100%, just do that and provide some override setting for "power users" so to speak.

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

#64

Post by toast0 »

trollied wrote: post #21

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!) :-)

Invalidation more or less doesn't work. Mandatory OCSP stapling could change that, maybe, but it also means your clients need to have much tighter time synchronization[1], and your servers need to be able to make the OCSP requests, and the OCSP servers need to have relatively high availability. An extended DDoS against an OSCP server in a mandatory stapling environment would effectively invalidate large numbers of certificates and be a real big mess.

[1] and no localtime bugs; I've worked with platforms that don't accept certificates where NotBefore interpreted in local time hasn't been reached. Which means you've got to let your certificates sit for hours before using them if you have customers in Hawaii or other pacific islands on this side of the date line.

At least certificate errors are big and in your face, unlike bgp and sometimes dns.

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

#65

Post by jrochkind1 »

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…

I seem to recall the browsers threatening to start issuing warnings for any http, but I guess it hasn't happened yet.

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

#66

Post by jrochkind1 »

bombcar wrote: post #62
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…

Especially since all Let’s Encrypt cares about us a DNS proof-of-domain, it should be possible to negotiate that from the browser itself.

It is probably easier to give a browser a fake DNS result (ie, a MITM attack) than to do the same to the letencrypt authorizers.

Fake DNS result/MITM is one of the things that the SSL cert is supposed to guard against. Possibly the only thing that a domain-validated cert has going for it over an anonymous cert. Allowing a domain cert to be "renegotiated" from the browser would seem to defeat the purpose of having a domain cert at all.

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

#67

Post by entropyie »

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…

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 learned is that even with the best of intentions, they are all fragile and their default state is broken, without constant maintenance.

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

In the past 20 years, all of the critical failures in PKI systems that I have seen were due to expiring certs, expiring CRLs, failure to distribute new PKI in time, accidental deletion of key PKI, missing intermediate certs. None were due to MITM, weak crypto, spoofed packets, use of plain HTTP. Make of that anecdote what you will.

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

#68

Post by lelanthran »

junon wrote: post #12
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 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.

> Security is not something to sacrifice to gain less angry users.

Of course it is - it depends on Capital-C-Context.

Sure, for the bank, the site you are supplying your credit card details, your email, etc - security is non-negotiable.

For hackernews, for reddit, and for similar sites, then security is something to sacrifice, once again depending on context.

I've trusted this certificate for the last 2, maybe 3 years. It's unreasonable to assume that 5 minutes past midnight on the expiry date, the cert turned from "completely trustworthy" to "100% certainty that this is a phish, scam or similar".

We live in the real world. Things happen.

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

#69

Post by lisper »

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 an expired cert (or self-signed cert) is better than nothing, and so a user should be allowed to proceed with a warning.

What neither side is acknowledging is that there is no one-size-fits-all solution because different sites have different threat models. HN has a very different set of risks associated with it than your bank.

Obviously, if you go to your bank's web site and it presents a cert that expired five years ago, you should probably not be allowed to proceed.

On the other hand, if you go to your family's static HTML photo site you should probably be able to access it without any encryption at all. Even sites like HN or Reddit are probably safe to visit unencrypted most of the time.

In between is a vast ocean of grey. Example: shortly before midnight you log in to your bank's web site to pay your credit card bill, which is due the next day. As you fill in the form, the clock ticks past midnight and the cert expires. It is the exact same cert that was valid five minutes ago when you logged in. Should you really be blocked from completing the transaction?

IMHO, at the very least certs should have two expiration dates, a soft one, at which point users get warnings, and a hard one, at which point the cert stops working. There are probably better solutions, but the idea that it's perfectly fine to visit a site one minute before midnight and unsafe one minute after is untenable.

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

#70

Post by ocdtrekkie »

junon wrote: post #12
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 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.

Here's the thing: Expired certificate warnings reduce security. Because they're excessively dramatic about a routine non-issue, people learn to ignore and bypass them. Now people won't head real certificate warnings.

Unfortunately, the browser security nerds don't understand human psychology, and are more scared of the fact an expired cert can't be revoked (a nearly pointless edge case) versus users ignoring all cert warnings entirely, which they do now. A classic example of engineers who don't understand their users.

Post reply on HN