It’s a hard problem: if you query on use, you not only introduce delay but also leak information about what servers people are connecting to. Dealing with that starts looking a lot more complicated (bloom filters per CA of recently-revoked cert IDs?) needing to be implemented into multiple libraries and the failure mode is an outage unless you fail open.
replySame here - I genuinely thought this would have been easily, and almost immediately, remediated vis-a-vis CRLs. I'm not in the vuln management space anymore, but is there some sort of caching system used which would affect software differently than a typical browser?
replyEditing to add a link to this Apple support article which is unsurprisingly detailed - https://support.apple.com/en-us/149555
As far as I'm aware the typical command-line stuff and most things just using SSL libs or language standard libraries don't do revocation at all by default.
replySimilar reason (though with the opposite effect) as how a cert can be fine for browsers but fail for curl when they don't send an intermediate: the "vanilla"/library/command-line stuff is just checking for a path to a trusted cert and not doing the CRL or AIA stuff a browser does.
Yes, exactly what the Apple article highlights! Appreciate the extra context.
replyCLI-based activity references etc/ssl/cert.pem. While they say this will be updated in the future (likely the next dot release), admins can also proactively remove the eMudhra entries.
[dead]
reply