11 ms·
What's the right UX for an expired certificate?
- C4K3 4y agoBrowsers could add the less severe warning before the certificate expires, for example 3 days before it expires have a "this certificate is about to expire, are you sure you want to continue?" warning. That would maintain the security guarantees around expiration while still getting the attention of users/administrators.
- bombolo 4y agoAlarm all the users to notify one person? Doesn't seem so good to me.
- yardstick 4y agoIsn’t that what happens now when the cert expires? Except when it’s expired it’s a lot harder for users to figure out how to bypass the warnings so they can visit the site to find a contact link to report the issue. Remember not every site is actively checked by their maintainer every day. In an ideal world it shouldn’t be needed (and likewise UX for expired certs wouldn’t be needed), but in practice I think it has merit.
- bombolo 4y agoOP's idea was to scare the users BEFORE it expires (and the admin still has time to renew). > Remember not every site is actively checked by their maintainer every day. Precisely… so scaring the users while the owner doesn't get the message is useless.
- yardstick 4y agoOwner will likely check their email more than visit their site. I know that’s true for various small sites of mine.
- groffee 4y agoThat's an absolutely terrible idea. Scaring the crap out of thousands of users when your certificates are set to auto-renew etc is just dumb.
- deleted 4y ago[deleted]
- INTPenis 4y agoReally interesting point. I've worked with CAs and TLS certs for 20+ years and this never even occurred to me. The UX is horrible, considering how many regular non-tech people an expired cert can affect. Imho the browser should continue showing its big full-page warning, but there should still be a way to proceed to the site. What if a cert expires on a life-saving service? And now the user can't even reach the site just because the time is wrong.
- forinti 4y agoJust 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.
- deleted 4y ago[deleted]
- lazyweb 4y agoOn 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.
- sublinear 4y agoNo 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'll be fine. Cryptography is a razor sharp thing. Treat it accordingly.
- junon 4y agoI 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.
- sublinear 4y ago[flagged]
- pittmajp 4y agoDisagree with your disagree. I understand there’s a recession and security people have to justify their salaries. The most secure system imaginable is for your users to shut their computers and go outside. If you can’t provide security without usability, your system is worthless. The truth is that users want products that feel secure, rather than products that are secure.
- junon 4y agoThis is a misguided and incorrect assessment except for your second point, IMO.
- lelanthran 4y ago> 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.
- entropyie 4y agoMy biggest issue with this whole situation, is that the user gets a better UX with no encryption whatsoever on a http:// http:// site than a self-signed or expired cert on https:// 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:// http:// traffic in a passive manner than it is to actively spoof a HTTPS:// connection. 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. Also, a user should be able to trust a specific cert once on first visit, and then be warned only if that cert changed. Also, the fact that the entire world's infrastructure relies on some small, centralised non-profit in the USA (LetsEncrypt) makes me very nervous. Ordinary citizens can end up on the wrong side of sanctions through no fault of their own...
- andirk 4y agoGood 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?
- entropyie 4y agoUltimately 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 warning. I could issue a cert claiming to be google.com without any deterance. Until recently all such authorities charged a fee to issue you a verified certificate. Also the process was usually not fully automated and required human intervention to renew a cert. LetsEncrypt was a major innovation for two reasons: 1. They provided the certificates for free, no strings attached 2. They provided a fully automated and optimized process to issue/renew/deploy the cert This had the effect of making HTTPS accessible to everyone, and is the reason that HTTPS has become the default rather than only being used for a small fraction of websites (e-commerce etc...). Overall this has been a positive development and has raised the bar against mass-surveillance across the world. However, the downside as mentioned, is that much of the world's infrastructure now relies on this small company. Since the certs are only valid for 3 months, any blockage in that renewal process means rapidly failing services.
- bluGill 4y agoWe have a repeatable build environment at work. However we can't rebuild anything from 2017 or before anymore because the environment back then doesn't have any valid certificates to validate servers downloading artifacts from, or that the artifacts signed back then are correct. Thus our build environment fails to be repeatable for long because the old environment cannot be used or duplicated 100%.
- entropyie 4y agoYes, and extending this to devices with embedded PKI, we are leaving a very poor legacy to our progeny. Look at all the amazing work being done to maintain old computers, software and games, from the 80's, like C64, NES, PDP-11, etc... What will our descendents be able to maintain from this period? Not much.
- trollied 4y agoIs 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!) :-)
- magicalhippo 4y agoI 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.
- crote 4y agoWe 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.
- toast0 4y agoInvalidation 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.
- steve1977 4y agoA user should not experience an expired certificate. Hence, the right UX is: null.
- alpaca128 4y agoSure, in a perfect world we shouldn't need debuggers, seatbelts, emergency services, insurances and many other things, but that's not how reality works.
- steve1977 4y agoWell, the debugger is a good example, because it’s also not something that concerns the end user, but only the developer. In the same way, certificate expiration is a problem that can easily and with 100% reliability be handled by operations. A end user should never be confronted with it.
- lisper 4y agoWow, 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.
- faeyanpiraat 4y agoNothing is safe without SSL (expired or not), if you are on public WIFI.
- entropyie 4y agoMost 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.
- indymike 4y agoThe 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.
- SilasX 4y agoSurprised to see no discussion of this in the context of browser extension signing, and Firefox's little fiasco. Apparently, Mozilla's best judgment is that, after expiry, the extensions should just stop working with no way to restore them ... even though this meant forced disabling of privacy features, which could have outed people and got them killed. https://news.ycombinator.com/item?id=19823701 https://news.ycombinator.com/item?id=19823701