I agree, from what I have seen online is that while Apple's OCSP responser was indeed soft-fail, it didn't have any short-term timeout so requests were left lingering. Due to it being soft-fail I've seen numerous posts detailing how to block the OCSP responder address either via DNS or via the terminal (not sure if you can disable revocation checking directly within settings). So this does seem to affect the industry as a whole.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, November 13th, 2020 at 21:30, Matthew Hardeman via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > In as far as that part of Apple's CA hierarchy is publicly trusted and > participates in the Mozilla Root CA program and that there were apparent > performance issues with ocsp.apple.com yesterday, I'm writing to suggest that > I believe there may be cause to expect some transparency regarding recent > Apple OCSP responder performance issues, whether those issues impacted > responses over covered certificates, what failures led to those issues, and > what remediations have been taken. > > I haven't seen any other mention of this and whether it rises as to the level > of an incident as yet. > > I clarify that I do not personally allege that I experienced a timeout or > long delay querying an in-scope certificate, but rather that infrastructure > that seems to be shared with publicly trusted signers had externally > detectable issues related to OCSP performance. > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
