CrLite Support

[mmouse]

Hello

well, this is coming from Mozilla

https://hacks.mozilla.org/2025/08/crlit ... n-firefox/

however, this seems nonetheless clever and interesting to me.

[Moonchild]

Pointless. We use the industry standard OCSP protocol (and stapled responses) to check revocation automatically.

[mmouse]

@moonchild

did you read the article, actually ?
It explains that
(under 'Better privacy and performance')
- OCSP is no longer mandatory and some certificate authorities are obsoleting it
- OCSP is not very good for privacy and that's a primary reason for dropping it

[Moonchild]

Deprecating OCSP is stupid.

CRLs are what we used to have before OCSP. Going back to that is taking a few steps backwards.
OCSP was never "mandatory" so that's a null argument. I'm sure they are thinking of bad CAs here that never revoke anyway (like Let's Encrypt) and have been eroding TLS trust for years because of it. No due diligence there, IMHO.
OCSP is perfectly fine for privacy, see stapled responses. OCSP servers are hardly ever contacted directly by the browser, especially if the "must-staple" directive is given.

Mozilla is full of shit in this respect, pardon my French.
But it makes sense for them wanting to "become a one-stop service provider". I believe they tried this before under a different name (OneCRL or something?). Don't buy into their ecosystem.

[mmouse]

Well, Sectigo (your certificate provider) voted for the change, so you will have to change your certs if you don't want to buy in this ecosystem; that's leaving only Certinomis, as it's the only one (out of 29) that has voted against.

[Moonchild]

Well, Sectigo (your certificate provider) voted for the change, so you will have to change your certs if you don't want to buy in this ecosystem

No, I don't have to change anything. If CAs stop supporting/running OCSP, then the revocation checks will simply fail and revoked certificates (relatively rare occurrence but an important part of the certificate authority setup) will pass as valid. IMO that is a failure by the CAs to ensure trust of the certificates they issue, and not of anyone else.
Of course CAs would be in favour of deprecating OCSP because from a business point of view, it's beneficial: not having to pay for the infrastructure is easily given preference over paying for it, regardless if the change would be a step back. If they can offload the responsibility to others, they obviously would.
It's still stupid - you're splitting the responsibility of certificate trust off from the CA. The "buying into the ecosystem" remark was that Mozilla would be happy to provide the service if it binds users to them. Keep in mind that CRLite is a Mozilla thing, and they will likely restrict it (with an API key/secret) to their published software only (Firefox can request CRL updates, other browsers probably can't). It is literally going back to the CRL days where revocation lists had to be distributed to every TLS client, only with the difference of the clients being vendor-locked to get certificate security updates...

Once again, there is no privacy issue with stapled OCSP responses as there will not be any request going outside of the server-client pair that is already aware of each other. This doesn't need to be changed, and the change proposed is a reduction in security. Stapled responses are short-lived by design. How quickly will a revocation of a cert pass through the vines to Mozilla to lead to a CRLite update to be distributed to all browsers? It's never going to be as quick as OCSP.

EDIT: From the article:

There are several reasons for this, but the foremost is that OCSP is a privacy leak. When a user asks an OCSP server about a certificate, they reveal to the server that they intend to visit a certain domain.

^this is simply not relevant. OCSP stapling (which is cryptographically secure) has been a thing for over a decade. The whole "When a user asks an OCSP server about a certificate" just doesn't happen, in practice. Mozilla's push here is conveniently leaving out the principal way revocation checks are performed these days. Raw OCSP server requests are very rare as just about every web server deployed on the Internet supports stapling, and all current browsers also do.

[Bilbo47]

the change proposed is a reduction in security.

Maybe to the browser, but when the proposers say this word, they are not talking about the browser. Instead, they are talking about the "security" of their business model, their cash flow, market capture, etc. Thus from their viewpoint the propsal is an *improvement* of security, and their marketing of the idea says so - just not in the same sense or meaning that the general public assumes.

[Moonchild]

the change proposed is a reduction in security.

Maybe to the browser, but when the proposers say this word, they are not talking about the browser. Instead, they are talking about the "security" of their business model, their cash flow, market capture, etc. Thus from their viewpoint the propsal is an *improvement* of security, and their marketing of the idea says so - just not in the same sense or meaning that the general public assumes.

That's really stretching it. After all the communication is with the public, and they strongly imply it's for the public's security ("if you don't do this, the people can snoop on your traffic"). I really don't think you should be defending it by some contorted explanation. It's just a lie.

[Kris_88]

In fact, to use OCSP stapling in a browser, it is necessary that this mechanism is enabled on the server. But not all servers support it. For example, Google and Facebook do not support it.
You can check here:
https://www.digicert.com/help/

[Moonchild]

Not sure why they wouldn't. It's easy to set up in all common web server software.

[Bilbo47]

the change proposed is a reduction in security.

when the proposers say this word, they are ... talking about the "security" of their business model

I don't think you should be defending it

I don't understand what you're saying by putting words in my mouth. To be clear, I agree with you the proposed change is not good for users.

[Moonchild]

Off-topic:

I don't understand what you're saying by putting words in my mouth.

I wasn't putting words in your mouth. You yourself seemed to be searching for some defense by making up a possible explanation "they meant something else than what was obvious". I'm pretty sure their "security" had nothing to do with business security and bringing that up seems to be searching for an "out" to somehow explain away the obvious problem.

[Bilbo47]

Off-topic:

You seemed to be searching for some defense by making up a possible explanation "they meant something else than what was obvious". bringing that up seems to be searching for an "out" to somehow explain away the obvious problem.

To clarify further: my intent was to expose / suggest an alternate or possibly additional reason why it's a problem. Don't know why you would so strongly ascribe or guess at other intent when maybe I wasn't clear enough.

In general, things that seem obvious are often presented in that fashion on purpose, so as to hide some true intent. The proof should be in the "why" such enshittifcation happens. I mean, they're claiming "security" but to people such as yourself who know how this stuff works, that claim is false on its face. So - if their stated reason is "obviously false", then what can their real reasons be? This is the kind of questioning that leads to perhaps-uncomfortable truths about the world.

[Moonchild]

Off-topic:
I may just have misread what you meant in that case. I apologize.

[mmouse]

This discussion has from my point of view comptetely gone off the rails.
I had the bad idea to include the remarks of the developer of this software about security and @Moonchild has discussed this (well, disputed).
The problem is that the facts of the matter discussed here, that is, the new version is or is not more secure, are totally irrelevant.
The only significant fact is that the ecosystem is changing and there is nothing that can be done about it.

To make my point of view any clearer, imagine that the road system involves mainly cars, and there are 3 big car producers totalling 99% of the market, and 20 oils producers providing 100% of the market. The oil producers and the car producers agree that a new formulation for the oil is better for whatever reason, and the cars must be updated accordingly to adapt to this new oil.
When you are a marginal car producer, does it make any sense for you to say to the users of your cars: 'this change is bad ! I won't care to adapt my product to it'; given that the car users won't find any oil compatible on the market ? even if your car + the old oil is better that the upgraded cars of your competitors + the new oil, it won't matter at all. The users of your cars will have to fill their tanks with an oil that will damage their motor and be a risk to them because it is the only oil that they will find on the market.

Now, I fully agree that this is not a priority. All that I was hoping that it would be acknowledged, and an issue be created in therepo to anyone to get and work on it if you personally don't have the time to.
It seems that it was expecting too much. All I can say is that it is sad.

[Moonchild]

The ecosystem may be changing, but CRLite is not a solution for us, because it is a vendor-specific implementation we will almost certainly have no access to without a keyed API, and we don't have the resources or bandwidth to implement and maintain our own vendor-driven revocation list solution ourselves, so in the meantime, we will be continuing to use the standardized and peer-agreed protocols that have worked well (or at least well enough) for decades. If this means revoked certificates will not be recognized as such, then that is the way it is, and is indeed a sad and sorry state of further reduced security in the TLS space. It cannot be the responsibility of individual web client publishers to adopt tasks and liabilities of CAs, certainly not if those CAs are the ones receiving the funds for issuing certificates.

[mmouse]

It is indeed unlikely that Mozilla will provide access to their servers to competing browsers. I don't see why they should (would you ?)

The server source code is available under the MPL. You may not want to use anything made by Mozilla, or you may be unable to dedicate a server for this use, but anyone can setup this kind of server using the Mozilla code or some alternate implementation written for the same use.
I have no doubt that the kings of NIH, Apple and Google, will develop alternate software with an incompatible protocol but I'm not sure that they will open source the server software. If is the case, they will crush Mozilla under their weight. But if not, the Mozilla one will be the only one that can be used without a big effort and more to the point, tested with only open source tools. I don't see any sane developer wanting to develop a new protocol so I expect that if there are alternate servers, they will be compatible with the Mozilla one.

I have looked a bit at the Mozilla server documentation and I agree that it's not pretty. Especially the use of Google Cloud Storage is repellent to me and I expect that developing a simpler storage would be *very hard* and probably rejected out of hand by the project. So it's probably better to wait for something less complicated to emerge.

[mmouse]

More info

https://letsencrypt.org/2025/08/06/ocsp ... nd-of-life

So Google has indeed its own system that may be simpler.

https://www.imperialviolet.org/2012/02/05/crlsets.html

Since Palemoon has also an update mechanism, this could be a way.

There is this small tool that seem to be able to download the list used by Chrome:

https://github.com/agl/crlset-tools

I compiled it and getting the update takes a few seconds (and my Internet connection is not fast). I did not take the time to check what this is doing, I assume that it's a differential list of current revocations (as signature for the certificates).

I also looked up on a few other projects that are not dominant browser : Ladybug: nothing in the issues (I understand that they never implemented OCSP), curl: nothing (they implement OCSP)

[Moonchild]

Feeling like a broken record here but I already said that for Let's Encrypt, OCSP isn't really a thing since they never revoked certs to begin with and have pushed for super short-lived certs instead. No revocations means OCSP for them is just dead weight. So it makes sense they switched it of for their particular context and it doesn't do anything for the threat model for their certs.

[Moonchild]

Maybe an overview is useful here:

FireShot Capture 35 - Cert revocation overv_ - file____E__webpages_Cert_20revocation_20overview.html.jpg

The main problem is that CAs are trying to "pass the buck" to others for what is actually their responsibility. They are both responsible for revoking certificates that have been compromised, and making sure that that revocation information gets distributed to end-users using their trust, one way or another. It doesn't have to be direct, but should be reasonably fast as compromised certificate misuse is very timing-dependent (if compromised it tends to be abused on very short notice, and abuse cases tend to be short-lived to not run the risk of getting caught/being able to "vanish with the proceeds"). A 12 hour delay can already cause significant damage to users, depending on context.