Based on this topic I'm now wondering, is there some system-wide or at least user-wide CRL push store on Linux that programs can share?
This site shows how to check it on a per-program basis, but if caching is done on a per program basis only for individual domains, if an attacker blocks the CRL URL access I assume this doesn't help much in that case. A system-wide store where the entire set of CRL for all CAs for the recent days is kept up-to-date though, would help. It seems like on Windows, this exists. Were e.g. the freedesktop people ever approached to perhaps make that happen, so that non-browser programs can benefit from it?
I'm also wondering how this would scale on slow connections, I assume the data in question might be a few dozen megabytes per week, so up to a few hundred megabytes per month. On e.g. mobile connections on the low end, I could potentially see that become an issue for some users.
My apologies if this was asked before, but the forum search doesn't seem to have brought anything up that was related.
Unlike most other operating systems, Linux doesn't have any OS-support for TLS/PKI: There's no platform-provided TLS implementation, no trust store and thus also no revocation cache.
Of course, an application can still develop such a mechanism and have others adopt it. For instance, several programs know about OpenSSL's /etc/ssl/certs "trust store" and can read that. But it's always on a per-program basis, as programs have to explicit add support for it. There's no platform support that is automatic as it is on e.g. Windows, iOS, or Android.
Because "Linux" isn't an operating system to begin with.
Looks like there are some implementations to 'fetch' CRLs like FetchCRL3 - PDP/Grid Wiki, but I'm guessing such applications won't make use of e.g. CRLite, but just regular CRLs.. However, it's quite impossible (in practice) for a regular person to fetch all possible CRLs out there..
Let me clarify it to "Linux kernel with GNU userland" then. glibc could technically always add stuff like this, but it's never really been aligned with their goals.
(There's technically also kTLS which I've intentionally ignored because it's really only a performance trick and not a real TLS implementation)
Well, nobody runs a Linux kernel with just the basic GNU / glibc stuff.. Almost always it includes other userland applications which can differ from distro to distro..
Thus, it wouldn't be unrealistic to claim that for these kind of problems, there might also be multiple ways of solving it with all kinds of software applications.. The GNU/Linux ecosystem has never been a 'one size fits all' kind of thing.
OCSP Stapling is just badly implemented and mostly useless. There seems little value in continuing to support if for the few situations it might have value. It has been broken for years (decades even) and seems as good a time as any to move forward to better options.
Perhaps CRL will have issues too but it's not like we are losing much by dropping OCSP. The idea that we have had a robust and reliable dynamic revocation is just faulty. The way forward is clearly short-lived certs.
As an aside, even thinking about "Must Staple" I recently found glaring failures. Chrome on Android, Edge on Windows, and Safari on iPad all ignored missing stapled responses for certs with "Must Staple".
Yes, certificate validation on Linux is a mess. As others have said different applications require a root store in different formats or locations, but it is worse than that. Most fill the content of these root stores by copying Mozilla's root store and removing Mozilla-specific attributes from the roots because applications can't read these attributes. But Mozilla has repeatedly said that using their root store while ignoring these attributes is insecure.
Huh, is there a root store for Linux that is a commonly available alternative that doesn't have that attributes stripped carelessly issue? And that might be worth bringing up here as well, if you want to jump in: freedesktop issue
I was just wondering if there was any news on Is there a CRL push infrastructure for Linux that can be hooked into? since it seems to be unsolved still. It seems like Linux is the most widely used operating system nowadays, so being able to TLS with a proper certs check on that system seems quite relevant. Especially now that let's encrypt is discontinuing OCSP.
Is there a particular TLS Client you think is losing something with LE switching off OCSP?
Because the few TLS clients I typically use don't check OCSP (on Debian). Not even for the leaf cert let alone any intermediates.
It's fair to ponder what could be. And I thought that's what you were asking earlier. But, when you say it is more important now that LE is dropping OCSP I wonder.
All clients on Linux worry me, since apparently Linux is the only system where there is 1. no cert store guaranteed available, and 2. if it is available it's apparently the mozilla store, apparently sometimes stripped for OpenSSL use in ways that were said above to be removing vital attributes to interpret it safely, and 3. apparently it doesn't integrate CRL push infrastructure whatsoever. If I understood that correctly at all. It seems like on Android, Windows, macOS those problems don't exist.
Isn't that a bit of an issue?
And regarding whether OCSP would have solved that or not, there seems to be a problematic on situation Linux in the present in any case. I'm wondering how to deal with that as an app dev.
Well, sure. But many TLS clients don't check OCSP today was my point. And, they haven't for years. The reasons for checking CRL are no different than the reasons that could have been motivating people to have used OCSP. Yet they haven't. So, why would they change now just because of the new CRL tech?
I personally don't think you'll get much traction on that but I am not faulting that effort in any way. I just wanted to understand why LE not offering OCSP changed the dynamic. And, it sounds like it has not.
The long-term trend is for short-lived certs. LE is currently testing issuance for 6day-ish certs (6d X hours I forget exactly). It will be a long time before every cert ever issued is this short. But, it is important as these short-lived certs do not need to carry either OCSP or CRL revocation info (although they can). The thinking is that the window for abuse is too small to have vast infra across the ecosystem to deal with that.
We will probably see servers diverge for a bit. Admins of critical and high-value targets will start using short-lived certs (and they can from Google Trust Services today). Even people with well-managed automated systems may well prefer those too. Others may stay with longer duration certs which are dropping to max of 47 days by 2029.
I think you'd better start with implementing openssl to able to parse full mozilla store parameters/crllite= I think most things using that in linux world (except something gnutls or embedded things)
Because I thought it actually has changed and browsers are checking that now. For other apps I wouldnt know, I guess that would depend on whether the TLS implementation on Android and Windows checks CRL by default.
In any case, thank you so much for the responses so far. It has been extremely enlightening and useful.
Checking that a cert is trusted is one thing. Dare I say all TLS Clients (browsers, curl, api, ...) on all platforms will check the trust chain or can readily be configured to. This often relies on the system's trusted root store. TLS clients check that the leaf cert chains to one of their trusted roots. This is a key element of TLS generally.
OCSP and CRL are used to check revocation status of a cert. This gets murky and the need for it and tradeoffs more complex. Support for that varies widely across apps and time. The Feisty Duck link I posted earlier has an excellent background.
Browsers on Linux may very well support CRL. They are complex apps. Firefox has historically been more strict about revocation checking than, say, Chrome. But that was with OCSP. Chrome likely supports CRL on various platforms. It is well beyond me to know what each browser does on which platform. They often also have settings to control exactly what they do (fail-safe, fail-hard, ...).
Revocation checking by other apps is even more complicated. And, I am certainly not the best person to address that either I do know that revocation checking in general is weak. Using powershell invoke-webrequest on Windows doesn't honor OCSP must-staple cert by default, for example. And neither does a native curl on Windows. I didn't check other OCSP issues or CRL but just pointing out that various apps do different things. I don't think there is default standardized revocation checking for all apps on any platform.
I do know that revocation checking in general is weak. Using powershell invoke-webrequest on Windows doesn't honor OCSP must-staple cert by default, for example. And neither does a native curl on Windows. I didn't check other OCSP issues or CRL but just pointing out that various apps do different things. I don't think there is default standardized revocation checking for all apps on any platform.