Corey QuinnIt’s a complete failure of infosec-meets-user-psychology that “this TLS certificate is issued for your bank and the server is sneaky hackerman dot com” and “this otherwise valid certificate expired a day ago” have the EXACT SAME USER EXPERIENCE.
hayden aiken 🇺🇲@Quinnypig I've been thinking about this a lot recently LOL. Since when do cert expirations regularly relate to a security problem or the site/vendor not being eligible to get new certs? Browsers seriously need to handle these openssl errors differently. It seems like openssl does have a bit of a "secure | there are errors" binary but it's not like the errors are opaque to the program...
Phil Dennis-Jordan@Quinnypig @aikensource Especially all the certificate typically proves is that the entity who held the cert’s private key at the time the cert was issued also had sufficient control over the domain or the thing connected to the IP it resolved to *on the day the cert was issued*. The weight that holds decreases over time - so an expired 1-month cert technically is more secure than an in-date 1-year cert.
@Quinnypig @aikensource I mean, allowing a live cert to expire, and by how much also signals something - but it’ll depend heavily on the type of entity (bank, government, key internet infrastructure mega corp, small business, Joe Bloggs) and the type of service we’re talking about. (Online banking, eGov service, eCommerce site, information-only website, …)
@Quinnypig @aikensource I could totally see a middle ground where browsers warn you about an expired cert without freaking out, but wipe/hide your cookies etc. if you continue, and yell at you if you try to enter a password or credit card number to the site.
@pmdj @Quinnypig yeah I think I agree on all counts. Chromium browsers already handle certain different errors a bit differently (basic ssl errors are easy to bypass, HSTS errors require advanced navigation) so they could probably design a way to handle diff circumstances of ssl errors a bit differently.
If I recall correctly, visiting an HTTP site is less intrusive and in-your-face than a 1 day expired cert from a major website lol.
Stuff like domains not matching.... That matters so much more.
If I recall correctly, visiting an HTTP site is less intrusive and in-your-face than a 1 day expired cert from a major website lol.
Stuff like domains not matching.... That matters so much more.
@Quinnypig @aikensource Yup, agreed. I think some years ago the browser makers announced they’d put unencrypted HTTP sites behind a similar scare-screen, but that never materialised due to the long tail of remaining unencrypted sites. But they kept the scare screens for the most basic TLS warnings, which as you say is wildly inconsistent.
ocdtrekkie@aikensource @pmdj @Quinnypig I will someday lose my **** over the fact that HSTS by specification requires browsers to refuse to operate as a user agent.
tolortslubor@aikensource @Quinnypig As an average Web user, I have assumed that if I visit a site with an expired certificate, Russian hackers will immediately seize control of my computer.
I think I’m gonna go rip a tag off my mattress now.
I think I’m gonna go rip a tag off my mattress now.
Not a doctor@tolortslubor @aikensource @Quinnypig
As a former #OfficeManager for a #DialUp #ISP I don't make assumptions about the #Allegiance, #Ethnicity, or #GeoLocation of the particular #CyberCriminals lurking on the other side of that mouseclick.
It's especially galling when it's my team's website is presenting me with this notificaiton.
Gerbrand van Dieyen@aikensource @Quinnypig I'd rather have a ssh like error, like the certificate has changed suddenly since your last visit.
rsalz@aikensource @Quinnypig I don't think any browsers use openssl now. The point is valid tho.
@rsalz dang it, you're completely right! I checked out the library dependencies for Chromium and Firefox, and they both use Mozilla's NSS, which is a comprehensive implementation of the same libraries as OpenSSL and more. TIL.
@aikensource Chromium uses BoringSSL. Maybe it uses NSS for some PKI code; I'm not sure.
@rsalz I saw that nss is a chromium dependency, my ignorance is showing tho
@aikensource they used to use NSS for the pkix stuff (cert validation, etc) and maybe they still do.
@Quinnypig I have been beating this drum for years, at browser companies keep making it *worse*, not better.
An expired cert should, at worst, be like, a yellow warning in the address bar for a month or two. There's *zero* justification for treating a barely expired certificate as a reason not to navigate to a page.
Worse yet is the absolute travesty that is HSTS, which then ensures you can't bypass the error for any reason, even if you understand why it happened.
Aaron GableExpired certs *have to* be treated exactly the same as revoked certs for two reasons, imo:
1) No one revokes certs after they expire. If a cert should be revoked (e.g. due to key compromise) shortly after it expires, it just won't be revoked instead. The browser must assume all expired certs may have been revoked, too.
2) If certs are allowed to function after they expire, the WebPKI loses agility. Enforcing expiry is how browsers ensure that BRs changes take effect.
2) WebPKI is mostly complete garbage and an embarrassment to the industry to begin with. Agility is another word for "fragility".
1) Is this a real world scenario, where you have ever experienced a security issue with a certificate which expired in less than a month?
Which is to say, certificate nerds' theories are being used to justify massive real world damage.
@asg @Quinnypig Don't get me wrong, Let's Encrypt is great at removing the highway robbery that was charged for a fundamentally useless layer of business process to generate a random number, thanks for that, but neither DV nor hard 12 month cert rotation requirements are meaningfully making anyone more secure.
Mark Penny@asg @ocdtrekkie @Quinnypig expired certs “drop off” CRLs (in most circumstances, code signing is one of the few usages where a cert with that key usage WON’T drop off a CRL.) Expiry of a certificate is checked (according to RFC 5280) PRIOR to revocation checking. Hence why expiry is considered “terminal” in terms of certificate validity.
@markpx509v3 @asg @Quinnypig Is this a practical concern or a theoretical one? My understanding is CRL checking not exactly ironclad to begin with. But the practical risk of expired certs appears to be still effectively nonexistent.
Can you give me an example of a real world attack that was done involving an expired certificate?
It's practical. The specifics of CRLs vs OCSP vs any other revocation checking mechanism don't matter; what matters is that a cert which *otherwise* would be revoked, in fact won't be, simply because it is already expired.
The easiest attack vector is:
- issue a cert for example.com, let it expire
- sell example.com to someone else. They revoke all extant certs, but don't revoke yours because it's expired.
- intercept their traffic, and use your expired cert for TLS
@ocdtrekkie @markpx509v3 So if you want expired certs to be trusted by browsers, you have to let expired certs be revoked. If you want to let expired certs be revoked, you have to change the Baseline Requirements, every existing CRL and OCSP implementation, and x509 itself. That's impractical.
Fundamentally, browsers have to choose *some* time to start treating an expired cert as equivalent to a revoked cert. The instant it expires is as good as any other time, and better than most.
@asg @markpx509v3 You can already request a valid certificate that's good for a year, and sell a domain to someone immediately thereafter, can you not? There's 364 days of valid certificate.
The instant is expires is absolutely the worst time to start treating an expired cert like a revoked cert, aforementioned 81% of organizations negatively impacted by issue caused solely by theoretical risks not used in practical attacks ever.
@ocdtrekkie @markpx509v3 Yes, but they can revoke that cert by virtue of controlling the domain name on it (revocation reason CessationOfOperation). CAs are required to respect this request by the BRs. They are no longer required to do so once the cert expires.
@asg @markpx509v3 Beyond the general issue of causing widespread issues solely based on PKI being designed by people who literally hate users, instantly rejecting expired certs has (rightfully) taught me to completely ignore browser cert warnings, and bypass nearly all of them by default.
@asg @markpx509v3 This has never gotten me to a bad place, so why would I ever stop? (Since this conversation started, I clicked a link on HP's website, which linked to a subdomain where their cert was expired a week ago, and I clicked through, and it in turn redirected me back to an HP site with a valid cert. I literally experience things like this... close to daily?)
I at least know the potential risks, but most people will both bypass these inane warnings while not understanding the risks.
@ocdtrekkie @markpx509v3 I guess I don't know what to say. I've worked in this field for a while now and in tech generally for much longer, and I have *never* clicked through an expired cert warning and refusing to do so has never negatively affected my experience.
Browsers blocking these sites works. Choosing to block them a day, a week, or a month after they expire simply kicks the can down the road.
Convince site operators to automate their issuance, not browsers to reduce user security.
@asg @markpx509v3 The thing is, the PKI structure doesn't actually increase user security. None of this nonsense has come from practical attacks.
And aren't we amongst the process of yet another of those highly vetted CAs getting distrusted for... never having been trustworthy to begin with?
Why do browsers trust a certificate signed for a US company in China more than a certificate that expired yesterday?
@asg @markpx509v3 I absolutely would have regular issues if I was scared to bypass a cert warning: They regularly impede my access to otherwise perfectly functional parts of the web, often to resources I need to do my job.
There's also basically no real world threat in doing so. Even "wrong domain" errors are exclusively misconfigurations in practice.
Automated issuance is great, but we're about a decade from when you can assume that's possible for all things.
@asg @markpx509v3 Also, domain validation isn't drastically good at proving to a human that the destination is trustworthy. Eventually when people figure out that security doesn't scale, we'll need a new flavor of Extended Validation (Verified Mark certificate, I guess is what we're going with for them now?)
And then we'll need a whole pile of new specs to determine if a site that uses DV instead of EV should be believed as secure on a given site or whatever. And it won't be automated. *shrug*
@ocdtrekkie Of course the WebPKI increases user security. Does it increase it *as much as one might hope*? No. But does it increase security over transmitting everything in plaintext, or having absolutely zero basis on which to make key trust decisions? Of course it does.
Since you're throwing around hyperbole instead of having a serious conversation about the pain points and merits of specific aspects of the current WebPKI, I'm muting this thread.
Steve "Looking for Work" Pordon (he/him/his)@ocdtrekkie @asg @markpx509v3 this is the exact scenario I point out in risk assessments when I find expired certs, along with things like "this cert expired a year ago, indicating a lack of site maintenance or monitoring." They're training end users to ignore potentially valid warnings. (Well, the browsers are training them in this case.)
@legion303 @asg @markpx509v3 Exactly. It's a case of alert fatigue, or a boy who cried wolf situation.
Rzbig
Markus Tacker@Quinnypig Developers be like: this is not supposed to happen. So we're good here.
Simon Frankau@Quinnypig TLS certificates expiring is just the enterprise-grade "you should regularly change your password".
opal hart@Quinnypig expiry should always be treated as seriously as though the certificate was manually revoked. ocsp revocations aren't even possible after expiry
Viss@Quinnypig i still think its kinda silly that browsers lose their shit over self-signed certs for rfc1918 addresses.
as if all the people who work on browsers have never bought a nas, or a router, or anything else thats an embedded device that lives on the lan which will likely never ever see a cert update.
@Viss @Quinnypig Lead browser developer/standards-setter doesn't believe you should have a NAS, doesn't agree with their business model.
kajer :notverified:Even better is when Google decided that using self-signed certs and CAs for 802.1x Wifi was insecure, and wouldn't let you use them in the local cert storage for system level things like wifi.
Google's rational was basically - "If you are deploying 802.1x, you can afford to buy a cert"
Daniel MartinOn a related point: it is *absolutely shameful* that I can't set up a CA locally for devices on my own rfc1918 network (using a .home DNS name) and have https "just work" without having each client trust a CA key that then can MITM *any* https content.
Why can't I say "trust this cert only to sign stuff in 192.168.*.* or with a *.myhomenet.home DNS name"?
My options for local-net https seem to be:
1) don't, http/plaintext only
2) errors that have to be ignored on every client every time
3) install a local CA cert on each client, making them fundamentally insecure and making me able to MitM any SSL traffic (as my phone will remind me every time I look at the settings page: "A certificate authority is installed on this device. Your secure network traffic may be monitored or modified.")
Nico̲las@fizbin You'll be happy to learn that you can say "trust this CA cert to sign only this stuff in subnet and domain". The term for these is certificate name constraints.
@nsd ooh, interesting. Yes, this does seem to be the sort of thing I've been wanting. I can't find any examples online that discuss limiting a cert to certain IP prefixes, but maybe I can work this out from diving into the documentation or trial and error.
@fizbin https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10 and search for "iPAddress" (spelled like that). IPv4 Subnets are encoded with 8 bytes, first the network address and then the mask. But tools often accept IP/mask notation.
Frost「
｜
｜霜の狼｜人面獣心」🐺❄️@fizbin @Viss @Quinnypig I think there's actually a restriction you can add these days to do that.
Not sure how widely supported it is though.
Also as always, OpenSSL is a fuck and it's really hard to do anything right with it.
Gina Häußge@Viss @Quinnypig This, so much this.
I maintain a piece of server software that endusers install on their own hardware. Endusers who rarely know what a CA is, who rarely own their own domain name, and who are completely out of their water to get SSL going there without scary browser warnings. And I can't do anything for them because the only thing I can do is shipping with a newly generated self signed and that generates catastrophic warnings too.
Justin Fitzsimmons@Quinnypig I see where you're coming from but neither the browser nor the user are really equipped to make a judgment about how much risk is incurred by an expired certificate. Defaulting to slamming the gate shut with a maximum alarm is really the only option since it provides the most protection to the user's privacy.
@smn Unfortunately it also lulls users into a false sense of “these warnings are unimportant.”
shawniganlaker@Quinnypig @smn "These warnings are an active nuisance I will endeavour to subvert."
lynni love badssl.com for showcasing all the nearly-identical error screens
chrome at least refuses to connect on some (unless u type the cheatcode `thisisunsafe`)
rolenthedeep@Quinnypig my favorite is "the certificate for 192.168.1.1 is not valid SOMEONE IS TRYING TO HACK YOU!!!"
I have severe TLS alarm fatigue. A bad cert on an unexpected site still raises an eyebrow, but I can see normal users being trained to just accept bad certs for this reason.
Jake@Quinnypig @mainframed767 how about we make a better process for ensuring certs are renewed? After all these years, why is it so difficult for an app to manage this process ongoing without much user intervention.
Lets Encrypt is good and its certainly easy enough to bake into an app lifecycle process. Surely they don’t have be the only one?
KeirFox@Quinnypig The bane of every IT worker.
Paul Crowley@Quinnypig What should the user experience for an expired certificate be?
@ciphergoth Something clearly distinct from a MitM attack?
Julien@Quinnypig TLS errors are the worst. Try having a wrongly configured Extended Key Usage… loads of fun…