4 ms·

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 previous

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

deleted 2y ago
[deleted]
andrewaylett 2y ago
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 2y ago
  There's OCSP Must-Staple, which makes MITM without stapling impossible. That is, if the client implements it and does not fail open. :)
thayne 2y ago
OCSP has problems too. 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.

deleted 2y ago

[deleted]

andrewaylett 2y ago

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 2y ago
There's OCSP Must-Staple, which makes MITM without stapling impossible. That is, if the client implements it and does not fail open. :)

thayne 2y ago

OCSP has problems too. 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.