letsencrypt / boulder

An ACME-based certificate authority, written in Go.
Mozilla Public License 2.0
5.15k stars 601 forks source link

Replace OCSP with CRLs #7312

Open aarongable opened 7 months ago

aarongable commented 7 months ago

This bug is an umbrella/tracking bug, acting as a one-stop-shop to see progress on the multiple sub-tasks necessary to achieve this large-scale project.

OCSP carries with it two large disadvantages: it is very high traffic and expensive for a CA to run, and it can theoretically leak browsing activity to CAs by observing streams of OCSP requests from a single client. Historically, these two disadvantages have been outweighed by the even larger disadvantage of CRLs: that they're huge, so unwieldy to work with that most clients simply don't. This disadvantage has, for web browsers at least, been largely mitigated by the advent of OneCRL and CRLite, methods by which browser vendors ingest and pre-process CRLs into much smaller formats, and push the results out to individual browsers via the browser's normal update mechanisms. As a result, the BRs were recently updated to allow CAs to omit OCSP information from certificates as long as they include CRL information instead. We intend to follow this path, and hope to significantly decrease costs by doing so.

Subtasks:

J0WI commented 1 month ago

I strongly disagree.

it is very high traffic and expensive for a CA to run, and it can theoretically leak browsing activity to CAs by observing streams of OCSP requests from a single client.

Both concerns are already addressed using OCSP stapling.

CRLs on the other hand have the drawback, that you cannot force a client to keep its list up-to-date. CRLs are usually only updated on a regular schedule. Therefore you still have the risk, that clients accept certificates that have been revoked recently. A malicious third party can also block CRL updates or if you are in a restricted network, like a captive portal or intranet, the client won't be able to validate the revocation status of a certificate while connecting to a service.

The announced breaking change breaks any certificate using the OCSP Must-Staple extension (RFC 7633). The ECH draft section 10.7 even recommends this to mitigate privacy leaks. (Disclaimer: I was in favor of this mitigation https://github.com/tlswg/draft-ietf-tls-esni/issues/156.)

Please let users the chance to choose whether they want to use CRL or OCSP.

Edit: The --must-staple feature is supported in Cerbot since 2016: https://github.com/certbot/certbot/issues/2626