return to table of content

Intent to end OCSP service

agwa
31 replies
1d2h

After I created OCSP Watch[1], I regularly detected CAs returning an OCSP response of unknown or unauthorized for certificates found in CT logs, indicating that they had basically forgotten that they had issued a certificate. I find that rather troubling. Indeed, OCSP Watch is currently reporting several forgotten NETLOCK certificates. (The certificates from other CAs are recently issued and will probably have OCSP responses provisioned in the near future.)

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.

[1] https://sslmate.com/labs/ocsp_watch/

nine_k
13 replies
1d

BTW what is the need for a CA to remember issued 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.

agwa
6 replies
1d

When a CA has an incident, such as learning that one of their domain validation methods is flawed, they need to be able revoke all certificates impacted by the incident. Without a reliable database of certificates, there's no guarantee they'll find all of the impacted certificates. OCSP could fail closed in this situation. CRLs always fail open.

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.

nashashmi
3 replies
1d

This central authority for certificate validation seems like extra infrastructure without which the internet fails.

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.

devman0
1 replies
23h43m

Could dust off DANE here, the connection probably already included a DNS lookup, why not get the public key info from the same.

tptacek
0 replies
18h50m

So many reasons, but the simplest is that those lookups will constantly fail because middleboxes makes variegated inane decisions about 53/udp and 53/tcp, which means you need to have a fallback mechanism, which will inevitably be exploitable. DANE is a dead letter.

nine_k
0 replies
22h45m

Between two distrusting parties, a third mediating party is needed. But that party does not need to be centralized. Indeed, there are many TLS certificate registrars.

jesboat
1 replies
23h58m

require sufficient info to identify the validation method to be included in an extension in the precert?

agwa
0 replies
22h39m

Yeah, that would be a good idea.

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).

phasmantistes
4 replies
1d

CAs need to know every certificate they've issued so that

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.

masklinn
2 replies
1d

Isn't it more "a lot" of certs? Surely if they need to revoke all certs they can just revoke the intermediate.

patrakov
1 replies
1d

There is a middle ground between "all certs" and "a few certs". An example would be https://community.letsencrypt.org/t/revoking-certain-certifi... (2.4% of all certificates). This needs a full list of affected certificates but is too small to revoke the intermediate.

masklinn
0 replies
23h57m

There is a middle ground between "all certs" and "a few certs".

And the GP used the word "all" which is what I was replying to.

magicalhippo
0 replies
19h27m

b) if they need to revoke all of their certs (e.g. due to discovering a validation process failure) they don't miss any.

Dumb q, but why not just revoke/invalidate the signing certificate used to sign the certificates?

fragmede
0 replies
1d

it's exactly that. the thing is that if you're a CA, that's not farfetched at all.

jaas
11 replies
1d

OCSP systems at scale are complex. At the core there is an on-demand or pre-signed OCSP response generation system, then there is usually an internal caching layer (redis or similar), then there is an external CDN layer. Just because the outer layer appears not to know about a certificate (a bug, to be sure), doesn't necessarily mean that other CA systems don't know about it.

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.

paulryanrogers
5 replies
20h22m

CAs are money printing machines. If they cannot even track the state of their delegated trust, then why should they be trusted themselves?! Trust is their core value proposition, the only reason they exist!

schoen
3 replies
20h15m

The person you're replying to (Josh Aas) is the head of the largest CA in the world, which has never charged anyone for a certificate and has never made a profit. That CA, at least, isn't a money-printing machine!

paulryanrogers
2 replies
19h0m

Good point. Though being a non-profit doesn't remove the fact that the value proposition of CAs is trust.

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.

dontdoxxme
0 replies
17h1m

Why don’t CT logs include revocations? Seems like that could provide transparency into this without the need for another system (OCSP)

phasmantistes
0 replies
20h16m

For what it's worth, the person you're replying to is the founder and executive director of Let's Encrypt, the non-profit free and open CA which decidedly isn't a money-printing machine.

lokar
2 replies
23h54m

They are so complex, and in practice unreliable, that my employer runs a caching proxy for our (non-browser) users (they mostly don’t want fail open).

IMO it is unfixable and should go

hsbauauvhabzb
1 replies
20h19m

I don’t understand what relevance your caching proxy has. if you have time, are you able to explain this a bit further?

lokar
0 replies
18h44m

The CA ocsp endpoints are so unreliable we have to run a cache (the sdk we provide will use it).

agwa
1 replies
1d

Do you disagree that OCSP would be significantly less costly and complex if the responder URL were not included in certificates, freeing the responders from having to serve hundreds of millions of clients?

jaas
0 replies
1d

Yes, I disagree. Best case scenario I think it would just allow us to get rid of the CDN layer. We'd still have to build and manage the rest with utmost care.

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.

dambi0
2 replies
22h33m

A unique per certificate CRL might work in theory. Theory is not the same as practice

mcpherrinm
1 replies
22h15m

Per-certificate CRLs are possible, though have about the same privacy problems as OCSP (without any of the possible advantages like OCSP pinning)

dambi0
0 replies
22h0m

Internal / private certificate distribution monitoring, but yes privacy beyond that.

kmeisthax
1 replies
23h12m

The CA did not forget the certificate if it's in their CT logs. The whole point of CT (unlike OCSP) is to make it impossible for a CA to forget what they've signed. If they forget to put a certificate in their CT logs, then the cert isn't valid. Anyone can download and retain copies of the logs, because they're signed and hash treed. Removing a cert after-the-fact is about as disruptive as editing Git history on Linus Torvalds' tree, meaning it will be incredibly obvious that the CA is trying to lie about what they signed.

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.

agwa
0 replies
22h21m

CT doesn't tell you if a certificate is revoked, so the CA still has to operate a revocation system. That revocation system can forget about certificates.

hlieberman
23 replies
1d2h

Why not simply add the Must Staple restriction unconditionally to all certificates (aka "status_request")?

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.

mcpherrinm
8 replies
1d1h

While it would eliminate privacy concerns, it would also likely break an enormous number of websites which don't implement OCSP stapling, or don't implement it correctly.

eqvinox
3 replies
1d1h

I'd suggest making browsers soft-enforce it with e.g. a yellow URL bar, giving server operators a window of time to fix things.

nick238
1 replies
1d

I think with the whole menagerie of green locks, green bars & EV sites replacing/cluttering the address bar (meh [0]), only showing PSL+1 [1] (which actually does help security, but vocal power-users hate [2])...UI/UX designers are probably loathe to mess with it again.

[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...

Dylan16807
0 replies
13h23m

Does highlighting the domain name not give the boost in security? I don't mind highlighting. And it's possible to get very aggressive with highlighting.

At the very least it should have a [...] and not completely hide the fact that there is a URL.

mcpherrinm
0 replies
1d

The browsers, generally, are not onboard with improving OCSP and supporting OCSP stapling. Chrome already doesn't check OCSP at all.

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...

doctorpangloss
3 replies
1d

You talk about it like there’s a vibrant community of websites out there. There’s streaming sites and social media, and then a bunch of apps that are delivered through the web. All of them are sophisticated web operations.

patmorgan23
0 replies
1h26m

The Internet is more than sophisticated big tech companies.

mcpherrinm
0 replies
22h47m

Let's Encrypt's goal has always been to support the vibrant community of websites, extending TLS to the long tail.

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.

fragmede
0 replies
1d

in practice I think you're right, but oof.

blahgeek
5 replies
1d1h

I don't get the OCSP Stampling protocol: if the server needs / is able to to contact the CA frequently anyway, why not simply use very short-lived certificates?

briansmith
3 replies
23h44m

Which CA's will issue short-lived certificates without negotiating a custom ($$$) contract with them?

kmeisthax
1 replies
23h10m

Let's Encrypt, they said a while back they want to allow issuing certs for fewer than 90 days.

schoen
0 replies
20h14m

That's true, although it's still not possible to actually get one yet.

agwa
0 replies
23h37m

Google Trust Services lets you go down to 1 day using ACME. No payment required.

eqvinox
0 replies
1d1h

Issuing a certificate has significantly more overhead (e.g. Certificate Transparency logs) than signing a statement that an existing certificate is still valid.

agwa
4 replies
1d2h

Many web servers have terrible to nonexistent OCSP stapling implementations.

darkhelmet
2 replies
23h3m

cough nginx. Nginx would start up and serve TLS on must-staple certs .. before doing the staple setup. ie: any client that validated that a must-staple cert had a stapled ocsp ticket would fail for the first few queries after nginx startup.

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.

agwa
0 replies
22h56m

Yeah, I looked into nginx's stapling implementation almost a decade ago. I fixed some simpler bugs (I submitted a patch which was mostly rewritten and then merged) but fixing the problem you mention would have required major re-architecting. I doubt it has changed.

eqvinox
0 replies
1d1h

This competes against terrible to nonexistent CRL checking on clients, but there are generally more clients than servers.

fiddlerwoaroof
1 replies
1d

OCSP sounds to me like a really bad idea: certificate expiration is already a significant cause of issues and now we add a whole new way for certificates to break your site?

ocdtrekkie
0 replies
4h40m

In practice, nothing breaks if it can't reach OCSP in a lot of cases. But as with most PKI systems, it causes problems sometimes, so we have to do stupid things like add firewall rules to allow secure systems to reach OCSP endpoints to avoid random PKI-dependent stuff coming crashing down.

citrin_ru
0 replies
1d

In addition to listed below performance is another concern - OCSP stapling make TLS handshake large and slower. While it removes need for the client to query OCSP server itself in practice it such queries happen infrequently, asynchronously and in some may not happen at all. In theory a clients could include Certificate Status Request into the Client Hello only when a local cache expires but IIRC a few years ago Firefox did request OCSP on every TLS handshake making every handshake large if stapling is enabled on the server.

c0balt
16 replies
1d2h

Interesting, how does the support for CRLs in web servers look?

Afaik, NGINX and Apache only have OCSP stapling support.

Asmod4n
13 replies
1d2h

Why would CRL require web server support?

iso8859-1
8 replies
1d2h

So that admins find out that the certificate they have configured is no longer valid.

Arnavion
2 replies
20h47m

Does ARI also return a suggested window of "right now" if the queried cert is manually revoked in the past? I was actually wondering this a few months ago when I implemented ARI in my ACME client - I also have a pending task to implement revocation checking, and if the ARI check makes that redundant it would be great. (Both the RFC and the LE blog only talk about querying ARI at some time before the CA decides to revoke the cert. My question is about querying ARI at some time after the user has revoked the cert.)

mcpherrinm
1 replies
17h3m

Yes, revoked certs will return "right now".

Arnavion
0 replies
14h49m

That's really nice. Thanks.

eqvinox
2 replies
1d1h

If your certificate has been revoked and you don't know that (e.g. from a very alarming e-mail), something has seriously gone wrong. In the general case, it'd be yourself requesting the revocation to begin with. But even if it isn't, I'm pretty sure the CA is supposed to tell you expeditiously.

phasmantistes
0 replies
1d1h

Not all subscribers provide email addresses through which they could be informed of a revocation.

mcpherrinm
0 replies
22h12m

Ideally your server handles this automatically, which is why Let’s Encrypt is working on extending ACME to help with this case.

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.

Asmod4n
0 replies
1d2h

You’d need a monitoring solution for that, your web server won’t just send you a mail when it’s cert got revoked.

The client does that for you, by checking back at the CA. No need for any configuration server side.

c0balt
3 replies
1d2h

To verify client and server certificates. For certificate-based auth this is quite important, but it's also nice to, e.g., know that your server cert is not revoked.

eqvinox
1 replies
1d2h

It's the client that is supposed to fetch the CRL. The server doesn't care unless it does client certificate authentication (which is incredibly rare due to poor UX.)

hunter2_
0 replies
1d1h

A server (nginx / httpd) might very well make outbound HTTPS calls and want to verify the origin's certificate to the fullest extent possible. This is known as a reverse proxy. However, many -- certainly not all -- reverse proxy configurations use origin servers that reside on the same exact network, and therefore don't need TLS connections (or use them with `SSLProxyVerify none` for e.g. self-signed certs to simplify things [0]), but I digress.

[0] https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslpr...

Asmod4n
0 replies
1d2h

Your client does the checking of the server cert, no need for any configuration server side.

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.

c0balt
1 replies
1d2h

Note: for nginx there is https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_... which needs to be pointed to a pem-encoded file with the CRL list (list of revoked certs).

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.

Arnavion
0 replies
20h39m

You were previously using OCSP stapling for your server cert. The CRLs containing your server cert have nothing to do with your server. The server config you have found is for nginx to verify client certs.

arsome
11 replies
1d2h

Disappointing to hear considering the limitations of CRLs - is there any intention to go forward with OCSP stapling or is that completely abandoned at this point?

tialaramex
10 replies
1d2h

My understanding is that stapling is the victim of the usual incompetence and laziness that infects a lot of systems where if one in a billion fail closed that would be considered a disaster but one in ten fail open is considered fine. You can't achieve meaningful security this way.

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.

eqvinox
9 replies
1d2h

The browser vendors have learned that you have to do it yourself

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.

tialaramex
8 replies
22h5m

It is called the Web PKI after all. If somebody else actually wants to do all the hard work they're welcome, but my impression is that there's only enthusiasm for bitching and whining which won't get the work done.

eqvinox
7 replies
21h58m

It is called the Web PKI after all.

Let's Encrypt issues X.509 certificates, not "Web PKI certificates".

mcpherrinm
6 replies
16h57m

x.509 is a certificate format used by many PKIs.

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.

eqvinox
5 replies
12h40m

Are you implying Let's Encrypt certificates should not be used for non-HTTP services?

nickf
3 replies
10h54m

What non-HTTP services need publicly-trusted certificates and care about revocation?

formerly_proven
2 replies
9h44m

mail

nickf
1 replies
6h0m

Like SMTP/IMAP etc? That would make sense, though I'm not sure how much revocation checking even happens there.

eqvinox
0 replies
42m

OCSP stapling: free feature of TLS library, works

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.

mcpherrinm
0 replies
1h28m

I am not implying that, but merely defining what the WebPKI is and where we fit into it.

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.

remram
10 replies
1d

So if I'm not using Chrome or Firefox, how do I check for revoked certificates? This just makes the web less open again.

agwa
9 replies
22h27m

To check if a certificate is revoked, you can look up its issuer in the CCADB (https://ccadb.my.salesforce-sites.com/ccadb/AllCertificateRe...) to find the URL(s) of its CRL(s), and then check the CRL(s) for the serial number.

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.

mcpherrinm
6 replies
22h1m

Let’s Encrypt will put CRL URLs in certificates before or when removing OCSP URLs, so no CCADB lookup should be required

remram
4 replies
18h29m

So my client should download the 100 MB CRL to check? Is that the secure workflow?

warhorse10_9
2 replies
17h49m

Modern crls are partitioned so this really isn’t a problem you will run into.

remram
1 replies
4h22m

Does that not recreate the privacy problem then, since the CRL server can see which CRL partition we download and when?

Should we expect CRL stapling?

mst
0 replies
3h1m

I think one would expect a partition to cover a lot of certificates for its size (or in the case of a compromise all certificates mapped to that partition) so I don't think you end up with nearly so meaningful a problem.

mcpherrinm
0 replies
17h10m

The largest Let's Encrypt CRL right now is 254 KB. Most are smaller. We might want to partition into smaller shards again to hit a bit smaller size than that in the future.

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.

agwa
0 replies
21h45m

Indeed! I forgot that the BRs mandate the CRLDP extension if the certificate lacks OCSP AIA.

So all (non-short-lived) certificates will continue to have a standard revocation checking mechanism encoded in them.

remram
1 replies
18h31m

I meant programmatically. The admin can also text me every time he revokes a certificate, but the point of CRL/OCSP/... is to not do that.

agwa
0 replies
17h4m

Everything I described can be done programmatically. I've written the code to do it.

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.

Sohcahtoa82
6 replies
1d1h

I'm curious how much of a factor this is. How often do certificates get revoked before expiration? I would think the only reason to revoke a certificate is if it was compromised.

agwa
4 replies
1d1h

Currently only 20,830,034 revoked certificates per my daily CRL download, versus ~1 billion active certificates. But the number of revoked certs could balloon if there's another Heartbleed-like event, or a mass misissuance.

mintplant
3 replies
1d1h

So are embedded devices just expected to not check for certificate revocation?

BertoldVdb
2 replies
20h53m

If you can tolerate some level of false positives you can turn the CRL into a bloom filter and save quite a bit of storage.

less_less
0 replies
3h21m

Depends how embedded and how many servers it's talking to. I'm also not sure you can really tolerate false positives, since the main domain you talk to might get revoked, but there are alternatives to Bloom filters that eliminate those. In any case it's going to be hard to go below about 0.8-1 byte per revoked cert (common case where most certs aren't revoked) even with a fancy data structure.

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.

kibwen
0 replies
4h8m

I don't think this comment deserves to be downvoted. For the specific constraints imposed by embedded environments, a bloom filter seems perfectly cromulent here. The odds of a false positive scale according to the amount of memory that you can afford, and even in the event of a false positive it would fail closed, which is a better security posture than not checking at all.

woodruffw
0 replies
1d1h

Compromised, or mis-issued. In practice, currently, mis-issuance is significantly more common (in terms of # of certificates revoked) than compromise is.

trillic
3 replies
1d2h

Are there any free or very inexpensive certificate providers which support ACME, DNS-01 challenges, and OCSP other than ZeroSSL?

agwa
0 replies
1d1h

Let's Encrypt will surely not be the only CA to discontinue OCSP after Microsoft removes their requirement.

notepad0x90
3 replies
23h31m

CRLs don't scale, that's their problem and they take too long to update.

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.

notepad0x90
0 replies
19h4m

Neat! and thanks for the response.

less_less
0 replies
7h0m

As a side project I also developed something like CRLite, but approximately 40% smaller: https://docs.rs/compressed_map/latest/compressed_map/

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.)

datadrivenangel
3 replies
1d2h

"As soon as the Microsoft Root Program also makes OCSP optional, which we are optimistic will happen within the next six to twelve months, Let’s Encrypt intends to announce a specific and rapid timeline for shutting down our OCSP services. We hope to serve our last OCSP response between three and six months after that announcement. The best way to stay apprised of updates on these plans is to subscribe to our API Announcements category on Discourse."

Interesting to see Microsoft dragging here.

mcpherrinm
0 replies
1h25m

Microsoft has always had stricter requirements for OCSP than the baseline requirements, which the other root programs have not had.

With the CA/Browser forum baseline requirements amended to no longer require OCSP, it is Microsoft's requirements alone that require OCSP.

agwa
0 replies
1d

Mozilla and Chrome were requiring it via the incorporation of the Baseline Requirements into their policies. The removal of the requirement from the BRs won't appear in the release notes of their policies.

eqvinox
2 replies
1d2h

I… er… what?

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] :(

andrewaylett
1 replies
1d1h

OCSP pretty much has to fail open, and stapling doesn't fix this.

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.

mhils
0 replies
21h36m

There's OCSP Must-Staple, which makes MITM without stapling impossible. That is, if the client implements it and does not fail open. :)

eduction
2 replies
1d1h

It would be nice if one didn't need to be a TLS expert to understand the post -- particularly since the whole point of Let's Encrypt was to democratize TLS access.

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.

[1] https://github.com/diafygi/acme-tiny

phasmantistes
0 replies
1d1h

Nothing will change for you, and nothing will break. The point of this post is to give a maximum-lead-time heads-up to the folks who _do_ need to care (the folks writing revocation-checking code in clients) so that later, more specific announcements don't come as a surprise.

mcpherrinm
0 replies
1d1h

For regular webserver users, accessed by web browsers, no changes are needed.

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)

codegeek
2 replies
1d2h

Can someone ELI5 what does this mean for people using LetsEncrypt today with servers like Nginx or Caddy ? Do we need to make any changes to adjust ?

mcpherrinm
0 replies
1d2h

For regular webserver users, accessed by web browsers, no changes are needed.

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.

candiddevmike
0 replies
1d1h

This mostly only impacts verification of Lets Encrypt certificates. No changes for ACME users.

newman314
1 replies
21h35m

Does anyone have a ready to go hosts blocklist for OCSP hostnames? Else, I could make one...

kroeckx
1 replies
15h25m

For the major browsers, this probably makes little difference, but for anything else, this will most likely result in not verifying the revocation status of certificates anymore or making things slower.

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.

dochtman
0 replies
1h25m

Making something like CRLite more like a standard seems worthwhile. I looked at the Mozilla bits but AFAICT there’s not much if any documentation of the low-level bits and pieces.

klysm
0 replies
1d1h

Certificate management is an interesting problem along the intersection of human behavior and computer science that feels similar to BGP. In theory, it's simple, but when met with reality things get messy really really fast.

jrochkind1
0 replies
1d1h

letsencrypt is the nonprofit community-focused infrastruture that we imagined the internet would consist of 20 years ago. I love you letsencrypt.