On Sat, Jan 08, 2022 at 01:05:41PM +1100, raf wrote:
> Probably no real harm done. OCSP stapling is just a way to make it
> more private and more efficient for a web browser to verify that a
> website's certificate hasn't been revoked, by providing that
> information in-band, so the browser doesn't have to contact your CA
> separately.
OCSP is mostly security theatre. Because stapling is optional,
attackers who fraudulently convince a CA to issue a rogue certificate,
(through MiTM or temporary control of your server) will not request
"must staple", and so the rogue certificate with be accepted without
server-mediated OCSP. Contacting the CA operated service as part
of mail delivery is a bunch of complex code that is far from appealing,
and at the end of the day TLS in SMTP is largely unauthenticated anyway.
So there's no point unless you do DANE, and with DANE there's no need
for CRLs or OCSP, just change your TLSA records to a "3 1 1" matching
keys the attackers are believed to not have compromised.
> But you might want "must staple" for your website, in case it's
> compromised, and the attacker turns off OCSP stapling, in the hope
> that clients won't bother checking revocation status, so they can keep
> using your certificate after you have revoked it. Having "must staple"
> would require the clients to check revocation status (via OCSP itself
> if stapling isn't offered), so they'd find out that you had revoked
> the compromised certificate.
The "must staple" extension is ineffective unless the signal is cached
for future connections that encounter a new certificate. I doubt that
all implementations do this, but perhaps some do.
--
Viktor.
