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