|
|
Log in / Subscribe / Register

Ever-growing CRL?

Ever-growing CRL?

Posted Dec 6, 2024 13:28 UTC (Fri) by mcatanzaro (subscriber, #93033)
In reply to: Ever-growing CRL? by NightMonkey
Parent article: Let's Encrypt sets date for ending OCSP support

Usage of actual CRLs is very limited. They are mostly supported by command line tools. No web browsers respect normal CRLs. I maintain the TLS integration in GNOME (glib-networking), which is based on GnuTLS. I refuse to support CRLs in GNOME for the reason you mention: they're too big and will tank performance. The security benefit is definitely not worth the cost.

Let's Encrypt is using the term "CRL" a little generously to additionally refer to proprietary solutions (proprietary as in nonstandard, not nonfree), specifically OneCRL from Mozilla and CRLSets from Chrome. The proprietary "delta CRLs" don't have any of these problems, but they are also not normal CRLs. I'm not interested in supporting them in GNOME because they are not Internet standards. To the best of my knowledge, they're really only used by Firefox and Chrome. I have ignored them. If one or the other could be standardized, then maybe it would be worth implementing in GnuTLS and OpenSSL? But as long as they remain nonstandard and not supported by TLS libraries, I don't care about them and users do not benefit.

In GNOME, the only supported form of certificate revocation is *stapled* OCSP. This doesn't have any privacy concerns that I'm aware of. We don't support TLS clients talking directly to OCSP servers (which is a terrible idea); instead, the TLS server is expected to talk to the OCSP server and "staple" the OCSP response by sending it to the client. It's only useful if you use the Must-Staple extension, though; otherwise, an attacker would simply not staple any OCSP response to guarantee no revocation. But it works. The Internet has collectively decided not to deploy it for unknown reasons; I'm really not sure why, because it's the only solution that really works. (Well, some sites deploy it. We've occasionally noticed certificate validation failures that don't occur in major web browsers when a website staples an invalid OCSP response.)


to post comments

Ever-growing CRL?

Posted Dec 7, 2024 9:14 UTC (Sat) by tialaramex (subscriber, #21167) [Link] (2 responses)

The nonstandard solutions like OneCRL are just generated from the CRL that Let's Encrypt and the like will deliver.

The browser vendors consume the various CRLs and produce their preferred data, since they own it they get to make the rules, which is beneficial to them and, arguably their users. Suppose a CA says we don't consider that what we did was mis-issuance for 8000 certs, so, we're just not marking them revoked. The vendor can say too bad, we're marking them revoked immediately anyway. Which is a smaller stick than "Since you were uncooperative we're distrusting you"

As with the Web PKI itself, there's a trade off to be made about what you hope to get out versus available resources to do the work. Consuming OneCRL means now you're stuck with Mozilla's choices on everything, but you need only barely enough volunteer effort to write and maintain the OneCRL consumption code, nothing more. A hypothetical GNOME-CRL built the same way would be able to do whatever GNOME wants, regardless of Mozilla, but incurs a considerable maintenance overhead forever.

The biggest thing I expect that a OneCRL is handling is bugs. My guess is that over a year probably half a dozen cases arise where oops, this CA turned off the machine that makes a CRL and so now it's just a 404 or a timeout, or doh, that other CA accidentally uploaded their CRL to the wrong URL every single day for the last six weeks, somebody fat-fingered the destination filename, fetch some-ca.example/CRM.dat instead of CRL.dat. Building a pipeline that's robust against the first sort of nonsense yet flexible enough to cope when the second sort happens will make these worth their time.

As to OCSP stapling, my understanding is that the HTTPS server software is just garbage - especially Apache - and this software has mostly rusted in place, so if you're in the browser client business you can't expect anything which requires the server software to be properly engineered to ever work, you have to base your assumptions on it's garbage, it will never be fixed and nobody who could do anything about that is interested in doing so. It's very much a case of if you don't Do It Yourself (as things like OneCRL do) then it won't get done. This is not a problem for the top 1% sites, your Facebooks, Youtubes, Wordle - somebody is getting paid to keep those working, and they probably read documentation and apply patches _they_ could have OCSP stapling (but many do not). But 99% of sites aren't like that, maybe they were thrown together by somebody's nephew six years ago and live "in the cloud" on a web server which is never maintained and will be gradually rusting until they're taken over by crooks or turned off. They're never getting OCSP-stapling.

Ever-growing CRL?

Posted Dec 7, 2024 14:09 UTC (Sat) by mcatanzaro (subscriber, #93033) [Link] (1 responses)

I don't think that's a great argument in support of OneCRL, because the end result is zero certificate revocation support for anybody who's not using the one or two applications that support the weird proprietary CRLs. Almost everything on your desktop is using GnuTLS or maybe OpenSSL and they simply do not implement nonstandard stuff.

I also don't think that's a even valid argument against OCSP stapling, since stapling is not mandatory, and theoretically only servers that support it properly would ever opt in.

Ever-growing CRL?

Posted Dec 16, 2024 5:14 UTC (Mon) by NYKevin (subscriber, #129325) [Link]

> I don't think that's a great argument in support of OneCRL, because the end result is zero certificate revocation support for anybody who's not using the one or two applications that support the weird proprietary CRLs.

Speaking as a Google employee who has no direct involvement with Chrome or Chromium, I would not describe OneCRL as "proprietary" when it has two independent FOSS client implementations. If other FOSS applications do not want to take code from Chromium or Firefox, that's a valid choice for them to make, but it does not mean that OneCRL is proprietary.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds