Intent to end OCSP service
letsencrypt.org
letsencrypt.org
CRLs can't be used to detect this, because they only list revoked certificates rather than providing a definitive status for every issued certificate.
I do wish the root programs had merely removed the requirement to include an OCSP URL in certificates, but required OCSP URLs for every issuer to be disclosed in the CCADB. That would have solved the privacy problems and made OCSP responders much cheaper to operate, while continuing to provide transparency into the status of certificates.
Certificates should work as long as they are not expired, not on a CRL, and while the same applies to their.CA's certificate used to sign it.
The only good use for remembering issued certificates that I see is that a CA could detect a compromise if it's handed a certificate it does not remember issuing. It looks far-fetched to me, but I know nothing about CA operation.
a) if they receive a request to revoke that certificate, they can actually do so; and
b) if they need to revoke all of their certs (e.g. due to discovering a validation process failure) they don't miss any.
And the GP used the word "all" which is what I was replying to.
In the same context, revoking the intermediate CA is bad in case some issued certificates were valid for an initial period, because then clients are unable to obtain fresh revocation information about issued certificates that would indicate the respective time of revocation (because the intermediate CA has to remain valid in order to be able to validate the signature on the OCSP response or CRL).
This is mostly not a concern in the context of TLS validation, because that usually relates only to the present time, not to times in the past, but it is relevant for code signing or other electronic signature use cases.
Dumb q, but why not just revoke/invalidate the signing certificate used to sign the certificates?
Aside: it was in fact envisioned that OCSP could be used to detect CA compromises, and the BRs used to say "The CA SHOULD monitor the OCSP responder for requests for 'unused' serial numbers as part of its security response procedures." I'm not sure how many CAs actually implemented that, and in any case I don't think it ever detected any compromises.
Once upon a time, internet communication was between two computers. Now there is a third computer to verify that the communication between two computers is legitimate.
Is there another communication design that works without the need for a third computer?
Edit: I don't think so. Identity validation of a public computer should be done by another well-trusted computer.
Though sometimes the CA needs to know more than just the validation method to determine if a certificate should be revoked, and it's not practical to stuff it all in an extension (e.g. this recent GoDaddy issue which required examining past CAA queries: https://bugzilla.mozilla.org/show_bug.cgi?id=1904748).
Requiring CAs to run OCSP makes running a CA more complex and expensive, which has considerable downsides like it does for any system, particularly as it is a zero sum game. Every dollar or hour of engineering time that Let's Encrypt spends on OCSP (and it is a considerable amount) is a dollar or hour not being spent on other parts of the CA. From the outside that may not be very visible because it's not obvious what isn't getting done instead but there is a real and considerable cost that is not worth it IMO.
Even that really depends on what the "SLA" expectation is. How many QPS would we be required to support before we're allowed to start dropping queries? If there's any possibility of a burst beyond what we can handle locally we'd keep the CDN, so maybe the CDN bill would be significantly smaller on account of lower volume but all the complexity and care of operation would still be there.
IMO it is unfixable and should go
Perhaps there is some compromise like they just have to submit all issuances certs to a 3rd party, and maintain the last few months worth of issuances.
The reason why OCSP forgets about certificates is that it was never intended to make CAs permanently remember every cert they ever signed. It was intended to replace CRLs with something less resource-intensive, except they screwed up the design, so it's now just a data siphon that provides little protection.
That will eliminate privacy concerns -- no compliant TLS implementation should fetch a OCSP ticket given a stapled response -- while still allowing for broad non-browser support.
I don't know if they've fixed it yet. I doubt it though - they were pretty aggressive in their assertion that violating must-staple wasn't a concern.
[0]: https://www.troyhunt.com/extended-validation-certificates-ar... [1]: https://blog.chromium.org/2020/08/helping-people-spot-spoofs... [2]: https://www.reddit.com/r/chrome/comments/h11gde/how_do_i_sto... [3]: https://www.wired.com/story/google-chrome-kill-url-first-ste...
At the very least it should have a [...] and not completely hide the fact that there is a URL.
Apple and Firefox are all working on out-of-band revocation information based on CRL data. Presumably Chrome and its family are going to go down that path too, but I'm not sure I've heard commitments from them yet.
Firefox has the best documentation on what's happening: https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a...
The handful of streaming and social media sites can always go to a big commercial CA and spend a few hundred bucks a year on certs that do whatever they need.
Interesting to see Microsoft dragging here.
[1]: https://wiki.mozilla.org/CA/Root_Store_Policy_Archive [2]: https://www.chromium.org/Home/chromium-security/root-ca-poli...
With the CA/Browser forum baseline requirements amended to no longer require OCSP, it is Microsoft's requirements alone that require OCSP.
As far as I know, most browser vendors already download the CRLs, and then update the browsers based on what they downloaded. For instance firefox seems to be using CRLite. There is a lack of support for something like that in the non-major browsers and non-browsers. The alternative they have is to download the CRL instead of the OCSP reply, which is larger, probably making things slower. Or they could just not check the status, which is most likely what will happen.
CRLite changes the failure mode of the status check, it no longer just ignores error in downloading the status information.
We need better support for something like CRLite.
My conclusion was that it isn't really practical unless you only trust one or two CAs.
Note this is still a long ways out. At this time, only people who are writing code against OCSP need to be aware of the future roadmap.
Afaik, NGINX and Apache only have OCSP stapling support.
So no API-based configuration, like OCSP stapling, that just works. I can probably try to configure this with a cronjob/systemd timer but this is significantly less ergonomic.
The client does that for you, by checking back at the CA. No need for any configuration server side.
https://letsencrypt.org/2023/03/23/improving-resliiency-and-...
Some good implementations of ocsp stapling can already automatically get a new certificate if they receive a “revoked” ocsp response.
Requiring humans to read their email and be looped in is work I want to avoid needing at all.
If you use certs for client auth it’s unlikely it’s used on the web and only in a company setting where you control the PCs, where you could just use something more suited for that case.
[0] https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslpr...
It's true this isn't an IETF standard (sometimes the IETF standards just don't work in practice) but the data is still very much in the open.
So all (non-short-lived) certificates will continue to have a standard revocation checking mechanism encoded in them.
Should we expect CRL stapling?
Shorter certificate lifetimes will also reduce CRL sizes.
A lot of traffic comes from browsers, or TLS stacks integrated with their host operating system, which we expect will use compressed push-based methods like Mozilla's CRLite to receive more efficient data structures as well.
One thing this announcement allows us to do is motivate us to start working on making CRL mechanisms more efficient.
But anyways, as mcpherrinm reminded me, certificates will still have the CRL Distribution Point extension so you can forget what I said about the CCADB and just do what the RFCs say.
Why isn't there a standard binary format for CRLs that is a cuckoo filter or a similar data structure? That way you don't have to worry about a CRL ballooning to gigabytes and you can expect clients to fetch the latest binary blob frequently.
We're getting there -- browser-summarized CRLs are available in Chrome and Firefox now
- https://letsencrypt.org/2022/09/07/new-life-for-crls.html
- https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a...
It's probably not state-of-the-art anymore, but it gets fairly close to the Shannon entropy of the {revoked, not revoked} distribution, supports non-Boolean types (like revocation reason), and is basically fast enough on both compression and queries.
The main missing functionality is incremental update. To implement daily updates you'd just compress "which certs were revoked today", and to check a 50-day-old cert you'd do 50 queries. (The queries are really fast tho, so that's probably fine.)
Data is on CRL availability, number of entries, expiry & refresh times, etc. from various x509 leaf server SSL certificates.
[1] https://news.ycombinator.com/item?id=41058138 [2] https://news.ycombinator.com/item?id=41046956
The browser vendors have learned that you have to do it yourself or it won't be done well enough to be useful. So you pull every CRL, do a bunch of compression or other tricks, then give your users that data and now they have working revocation.
When Bob's CA and Kebab Shop breaks their revocation stack, instead of dozens of poor individual users or web site owners confused and calling Bob's outsourced call centre in Pakistan with no sign of a fix, now a Google account exec asks Bob's CTO whether they forgot to say they were getting out of the CA business...
I agree this isn't a desirable outcome, but it might be all we have.
Cool. We already got the internet ossified on TCP + UDP, other L4 protocols just get stuck in firewalls and whatnot. Now we're progressing in ossification of HTTP. <insert expletives here>
To be clear: this OCSP decision seems to be driven directly and only by web/HTTP consumers. Anything else is just not considered.
Let's Encrypt issues X.509 certificates, not "Web PKI certificates".
Let's Encrypt is a CA that is part of the WebPKI.
We follow standards set by the CA/B forum, undergo WebTrust Audits, and are accepted into the root programs run by the browser vendors (Primarily: Apple, Mozilla, Microsoft, and Chrome). That is the WebPKI.
OCSP must-staple: free feature of TLS library, works
plain OCSP: hit & miss, depends on the client software using the TLS library correctly
CRL: no.
… that's the crux of this entire thread.
Let's Encrypt's primary goal is to encrypt the web, and most of our decision making is based on that. It isn't so much about HTTP as it is the ecosystem.
You can use our certificates for any TLS Server use-case. I wouldn't suggest using our certificates for things which aren't TLS servers, though.
(The services are all TLS based. They are just not HTTP based, and CRLs are generally delivered via HTTP. And I'm not going to wrangle a HTTP client into my mail server, or worse, postgres instance. The latter could also work with a local CA, it's primarily SMTP that doesn't.)
(...or I just ignore revocation and cross my fingers it'll never come up...)
> Our new CRL URLs will be disclosed only in CCADB, so that the Apple and Mozilla root programs can consume them without exposing them to potentially large download traffic from the rest of the internet at large.
You will surely want to shard the CRL, so if the device only accesses a few servers (and thus only has a few shards) then it'll be fine, but if it accesses many servers then there will be trouble, and you'll want to reserve extra space in case of a mass revocation.
Wasn't the point of OCSP to provide a low-latency and low-data alternative to CRLs, which might become massively huge?
First of all, privacy was one of the points of OCSP stapling.
Second, this breaks all non-http applications in the sense that they could previously work through OCSP stapling which would be communicated in-line. CRLs need to be fetched by the client, generally over HTTP.
Third, most non-browser TLS clients simply do not fetch CRLs, the implementation hurdle was too high.
… I'm left seriously befuddled by this decision by Let's Encrypt [edit: or rather the CA/B forum] :(
If you're in a position to MITM a client using an exfiltrated certificate that no longer passes OSCP, you're probably also in a position to block the request to the OSCP server. And you're not going to staple while you MITM.
As a client, you can't really tell the difference between "this certificate is valid but not stapled and the OSCP server is down" and "this certificate isn't stapled because I'm being MITM'd, and the OSCP server is blocked".
For those who could successfully staple, really short-lived certificates might be a suitable answer -- that's effectively what OSCP gave you, only without actually ensuring that the certificate would cleanly expire.
Al ot of non-browser applications just don't bother checking revocation. Which is terrible, but there aren't currently any good options. The best solution would be making cert lifetimes short enough that you don't need revocation, or making OCSP stapling, or something similar mandatory. But rolling either of those out across the whole internet would be slow and difficult.
I have no idea if this means my setup will break even after consulting the docs of my ACME client.
Can I still use ACME Tiny[1] with nginx? Any reason to think that will break? How can I tell if I'm using OCSP or CRL?
Totally incomprehensible blog post.
Note this is probably at least a year, if not more, away.
I'm sorry this post wasn't accessible enough, and we'll have more communications in the coming years as this gets closer.
(I work at Let's Encrypt and proofread this post before publishing)